pci overmapping
Kumar,
In fsl_pci.c there is a change you made a while back:
powerpc/fsl: Setup PCI inbound window based on actual amount of memory
...and there is this comment in the code:
/* PCIe can overmap inbound outbound since RX TX are separated */
if (early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP)) {
You are implying that PCIe can overmap and PCI can't. Why is
that? (I'm assuming that 'overmap' means that inbound window
can extend beyond the end of ram.)
We are facing an issue for a non-PCI express controller (i.e. without
PCI_CAP_ID_EXP) emulated by QEMU. In our case we need the ATMU
window to extend beyond the end of ram, since the window size has
to be a power of 2.
Thanks,
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver.
-Original Message- From: Joerg Roedel [mailto:j...@8bytes.org] Sent: Tuesday, April 23, 2013 8:39 AM To: Sethi Varun-B16395 Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org; Yoder Stuart-B08248; Wood Scott-B07421 Subject: Re: [PATCH 2/3 v14] iommu/fsl: Add additional iommu attributes required by the PAMU driver. On Tue, Apr 23, 2013 at 10:05:25AM +0530, Varun Sethi wrote: Added the following domain attributes for the FSL PAMU driver: 1. Added new iommu stash attribute, which allows setting of the LIODN specific stash id parameter through IOMMU API. 2. Added an attribute for enabling/disabling DMA to a particular memory window. 3. Added domain attribute to check for PAMUV1 specific constraints. Signed-off-by: Varun Sethi varun.se...@freescale.com --- v14 changes: - Add FSL prefix to PAMU attributes. v13 changes: - created a new file include/linux/fsl_pamu_stash.h for stash attributes. v12 changes: - Moved PAMU specifc stash ids and structures to PAMU header file. - no change in v11. - no change in v10. include/linux/fsl_pamu_stash.h | 39 +++ Isn't asm/ for your architecture a better place for that header? The PAMU isn't strictly tied to Power architecture, although that is where it is implemented now. It could be implemented on ARM for example. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Thursday, April 04, 2013 10:22 AM To: Sethi Varun-B16395 Cc: Joerg Roedel; Yoder Stuart-B08248; Wood Scott-B07421; io...@lists.linux-foundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On Thu, 2013-04-04 at 13:00 +, Sethi Varun-B16395 wrote: -Original Message- From: Alex Williamson [mailto:alex.william...@redhat.com] Sent: Wednesday, April 03, 2013 11:32 PM To: Joerg Roedel Cc: Sethi Varun-B16395; Yoder Stuart-B08248; Wood Scott-B07421; io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linux- ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote: Cc'ing Alex Williamson Alex, can you please review the iommu-group part of this patch? Sure, it looks pretty reasonable. AIUI, all PCI devices are below some kind of host bridge that is either new and supports partitioning or old and doesn't. I don't know if that's a visibility or isolation requirement, perhaps PCI ACS-ish. In the new host bridge case, each device gets a group. This seems not to have any quirks for multifunction devices though. On AMD and Intel IOMMUs we test multifunction device ACS support to determine whether all the functions should be in the same group. Is there any reason to trust multifunction devices on PAMU? [Sethi Varun-B16395] In the case where we can partition endpoints we can distinguish transactions based on the bus,device,function number combination. This support is available in the PCIe controller (host bridge). So can x86 IOMMUs, that's the visibility aspect of IOMMU groups. Visibility alone doesn't necessarily imply that a device is isolated though. A multifunction PCI device that doesn't expose ACS support may not isolate functions from each other. For example a peer-to-peer DMA between functions may not be translated by the upstream IOMMU. IOMMU groups should encompass both visibility and isolation. I also find it curious what happens to the iommu group of the host bridge. In the partitionable case the host bridge group is removed, in the non-partitionable case the host bridge group becomes the group for the children, removing the host bridge. It's unique to PAMU so far that these host bridges are even in an iommu group (x86 only adds pci devices), but I don't see it as necessarily wrong leaving it in either scenario. Does it solve some problem to remove them from the groups? Thanks, [Sethi Varun-B16395] The PCIe controller isn't a partitionable entity, it would always be owned by the host. Ownership of a device shouldn't play into the group context. An IOMMU group should be defined by it's visibility and isolation from other devices. Whether the PCIe controller is allowed to be handed to userspace is a question for VFIO. Thanks, Right now the add_device() callback gets called for all platform devices (including PCI controller) and PCI devices. PCI controllers are a kind of special case in that their device tree node has a property indicating that it is DMA capable...but in fact the PCI controller itself does not DMA, but it's the PCI endpoints under it. So, as you noted the bridge/controller shouldn't be in an IOMMU group and so since the platform 'add device' code didn't special case PCI controllers, this patch removes their group if it's there. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Sethi Varun-B16395 Sent: Wednesday, April 03, 2013 12:12 AM To: Wood Scott-B07421; Timur Tabi Cc: Joerg Roedel; lkml; Kumar Gala; Yoder Stuart-B08248; io...@lists.linux-foundation.org; Benjamin Herrenschmidt; linuxppc-dev@lists.ozlabs.org Subject: RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. -Original Message- From: Wood Scott-B07421 Sent: Wednesday, April 03, 2013 7:23 AM To: Timur Tabi Cc: Joerg Roedel; Sethi Varun-B16395; lkml; Kumar Gala; Yoder Stuart- B08248; io...@lists.linux-foundation.org; Benjamin Herrenschmidt; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. On 04/02/2013 08:35:54 PM, Timur Tabi wrote: On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel j...@8bytes.org wrote: + panic(\n); A kernel panic seems like an over-reaction to an access violation. We have no way to determining what code caused the violation, so we can't just kill the process. I agree it seems like overkill, but what else should we do? Does the IOMMU layer have a way for the IOMMU driver to stop the device that caused the problem? At a minimum, log a message and continue. Probably turn off the LIODN, at least if it continues to be noisy (otherwise we could get stuck in an interrupt storm as you note). Possibly let the user know somehow, especially if it's a VFIO domain. [Sethi Varun-B16395] Can definitely log the message and disable the LIODN (to avoid an interrupt storm), but we definitely need a mechanism to inform vfio subsystem about the error. Also, disabling LIODN may not be a viable option with the new LIODN allocation scheme (where LIODN would be associated with a domain). I think for phase 1 of this, just log the error, shut down DMA as you described. We can implement more full featured error management, like notifying vfio or the VM somehow in the future. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Sethi Varun-B16395 Sent: Thursday, March 28, 2013 2:54 PM To: j...@8bytes.org; Yoder Stuart-B08248; Wood Scott-B07421; io...@lists.linux-foundation.org; linuxppc- d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; ga...@kernel.crashing.org; b...@kernel.crashing.org Cc: Sethi Varun-B16395 Subject: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation. Following is a brief description of the PAMU hardware: PAMU determines what action to take and whether to authorize the action on the basis of the memory address, a Logical IO Device Number (LIODN), and PAACT table (logically) indexed by LIODN and address. Hardware devices which need to access memory must provide an LIODN in addition to the memory address. Peripheral Access Authorization and Control Tables (PAACTs) are the primary data structures used by PAMU. A PAACT is a table of peripheral access authorization and control entries (PAACE).Each PAACE defines the range of I/O bus address space that is accessible by the LIOD and the associated access capabilities. There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT (SPAACT).A given physical I/O device may be able to act as one or more independent logical I/O devices (LIODs). Each such logical I/O device is assigned an identifier called logical I/O device number (LIODN). A LIODN is allocated a contiguous portion of the I/O bus address space called the DSA window for performing DSA operations. The DSA window may optionally be divided into multiple sub-windows, each of which may be used to map to a region in system storage space. The first sub-window is referred to as the primary sub-window and the remaining are called secondary sub-windows. This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c) has been derived from the work done by Ashish Kalra and Timur Tabi. Signed-off-by: Timur Tabi ti...@tabi.org Signed-off-by: Varun Sethi varun.se...@freescale.com --- changes in v11: - changed iova to dma_addr_t in iova_to_phys API. changes in v10: - Support for new guts compatibe string for T4 B4 devices. - Modified comment about port ID and mentioned the errata number. - Fixed the issue where data pointer was not freed in case of a an error. - Pass data pointer while freeing irq. - Whle initializing the SPAACE entry clear the valid bit. changes in v9: - Merged and createad a single function to delete a device from domain list. - Refactored the add_device API code. - Renamed the paace and spaace init fucntions. - Renamed functions for mapping windows and subwindows. - Changed the MAX LIODN value to MAX value u-boot can program. - Hard coded maximum number of subwindows. changes in v8: - implemented the new API for window based IOMMUs. changes in v7: - Set max_subwidows in the geometry attribute. - Add checking for maximum supported LIODN value. - Use upper_32_bits and lower_32_bits macros while intializing PAMU data structures. changes in v6: - Simplified complex conditional statements. - Fixed indentation issues. - Added comments for IOMMU API implementation. changes in v5: - Addressed comments from Timur. changes in v4: - Addressed comments from Timur and Scott. changes in v3: - Addressed comments by Kumar Gala - dynamic fspi allocation - fixed alignment check in map and unmap arch/powerpc/sysdev/fsl_pci.h |5 + drivers/iommu/Kconfig |8 + drivers/iommu/Makefile |1 + drivers/iommu/fsl_pamu.c| 1269 +++ drivers/iommu/fsl_pamu.h| 405 + drivers/iommu/fsl_pamu_domain.c | 1137 +++ drivers/iommu/fsl_pamu_domain.h | 85 +++ 7 files changed, 2910 insertions(+), 0 deletions(-) create mode 100644 drivers/iommu/fsl_pamu.c create mode 100644 drivers/iommu/fsl_pamu.h create mode 100644 drivers/iommu/fsl_pamu_domain.c create mode 100644 drivers/iommu/fsl_pamu_domain.h Ack. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig
-Original Message- From: Michael Neuling [mailto:mi...@neuling.org] Sent: Thursday, March 21, 2013 6:21 PM To: Chen Gang F T; Yoder Stuart-B08248; Kumar Gala Cc: Chen Gang; Benjamin Herrenschmidt; s...@canb.auug.org.au; pau...@samba.org; m...@ozlabs.org; imun...@au1.ibm.com; linuxppc-dev@lists.ozlabs.org; linux-ker...@vger.kernel.org Subject: Re: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig Chen Gang F T chen.gang.flying.transfor...@gmail.com wrote: it seems: only move slb_miss_realmode to the end, can fix this issue without negative effect. So this works but uncovers a new bug. Stuart: if you apply this patch allmodconfig now gets this build error on linux-next. arch/powerpc/kernel/built-in.o: In function `restore_pblist_ptr': ftrace.c:(.toc+0xd78): undefined reference to `epapr_ev_idle_start' ftrace.c:(.toc+0xd88): undefined reference to `epapr_ev_idle' make[1]: *** [vmlinux] Error 1 Reverting your patch below fixes this: commit f070986a07e514e3b4fc4aef6551b8dffcb19287 Author: Stuart Yoder stuart.yo...@freescale.com Date: Fri Feb 8 13:22:56 2013 -0600 powerpc: Add paravirt idle loop for 64-bit Book-E Signed-off-by: Stuart Yoder stuart.yo...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org Should we revert your patch or can you send a fix? This is currently broken in linux-next (at least next-20130321). Sent a patch that resolves this. Not completely happy with it because of the added #ifdefs, but not sure how else to resolve this. allmodconfig is creating config combinations that don't happen in a normal build (at least currently)-- 64-bit build that enables EPAPR_PARAVIRT but not PPC_BOOK3E_64. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation.
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Thursday, March 14, 2013 3:20 PM To: Sethi Varun-B16395 Cc: j...@8bytes.org; io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linux- ker...@vger.kernel.org; b...@kernel.crashing.org; Wood Scott-B07421; Yoder Stuart-B08248 Subject: Re: [PATCH 5/5 v9] iommu/fsl: Freescale PAMU driver and iommu implementation. On Mar 13, 2013, at 1:49 PM, Varun Sethi wrote: +/* + * Table of SVRs and the corresponding PORT_ID values. + * + * All future CoreNet-enabled SOCs will have this erratum fixed, so this table + * should never need to be updated. SVRs are guaranteed to be unique, so + * there is no worry that a future SOC will inadvertently have one of these + * values. + */ Maybe add to the comment about what port_id represents When you update the comment, I would also suggest identifying the specific errata here (A-004510) so that it's easy to reference back to the specific issue this code is fixing. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v2] powerpc/e6500: Add Power ISA properties for e6500 cores
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, March 05, 2013 2:29 PM
To: Yoder Stuart-B08248
Cc: ga...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org; Yoder
Stuart-B08248
Subject: Re: [PATCH][v2] powerpc/e6500: Add Power ISA properties for e6500
cores
On 03/05/2013 02:16:42 PM, Stuart Yoder wrote:
From: Stuart Yoder stuart.yo...@freescale.com
Signed-off-by: Stuart Yoder stuart.yo...@freescale.com
---
-v2
-fix some typos
arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi | 65
1 file changed, 65 insertions(+)
create mode 100644 arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi
b/arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi
new file mode 100644
index 000..6b4d16a
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/e6500_power_isa.dtsi
@@ -0,0 +1,65 @@
+/*
+ * e6500 Power ISA Device Tree Source (include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following
conditions are met:
+ * * Redistributions of source code must retain the above
copyright
+ * notice, this list of conditions and the following
disclaimer.
+ * * Redistributions in binary form must reproduce the above
copyright
+ * notice, this list of conditions and the following
disclaimer in the
+ * documentation and/or other materials provided with the
distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote
products
+ * derived from this software without specific prior written
permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms
of the
+ * GNU General Public License (GPL) as published by the Free
Software
+ * Foundation, either version 2 of that License or (at your option)
any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor AS IS AND
ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE
FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/ {
+ cpus {
+ power-isa-version = 2.06;
+ power-isa-b;// Base
+ power-isa-e;// Embedded
+ power-isa-atb; // Alternate Time Base
+ power-isa-cs; // Cache Specification
+ power-isa-ds; // Decorated Storage
+ power-isa-e.ed; // Embedded.Enhanced Debug
+ power-isa-e.pd; // Embedded.External PID
+ power-isa-e.hv; // Embedded.Hypervisor
+ power-isa-e.le; // Embedded.Little-Endian
+ power-isa-e.pm; // Embedded.Performance Monitor
+ power-isa-e.pc; // Embedded.Processor Control
+ power-isa-ecl; // Embedded Cache Locking
+ power-isa-exp; // External Proxy
+ power-isa-fp; // Floating Point
+ power-isa-fp.r; // Floating Point.Record
+ power-isa-mmc; // Memory Coherence
+ power-isa-scpm; // Store Conditional Page
Mobility
+ power-isa-wt; // Wait
+ power-isa-64; // 64-bit
+ power-isa-e.pt; // Embedded.Page Table
+ power-isa-e.hv.lrat;// Embedded.Hypervisor.LRAT
+ power-isa-e.em; // Embedded Multi-Threading
+ power-isa-v;// Vector (AltiVec)
+ power-isa-er; // Enhanced Reservations (Load
and Reserve and Store Cond.)
+ power-isa-deo; // Data Cache Extended
Operations
ER and DEO are FSL EREF categories, not Power ISA categories.
Ok, so not Power ISA strictly speaking, but are architectural
categories. So should we invent a new convention of fsl-eref-*??
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
-Original Message-
From: Sethi Varun-B16395
Sent: Monday, March 04, 2013 5:31 AM
To: Stuart Yoder
Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
linux-ker...@vger.kernel.org; Wood
Scott-B07421; Joerg Roedel; Yoder Stuart-B08248
Subject: RE: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU API
implementation.
-Original Message-
From: Stuart Yoder [mailto:b08...@gmail.com]
Sent: Saturday, March 02, 2013 4:58 AM
To: Sethi Varun-B16395
Cc: io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org;
linux-ker...@vger.kernel.org; Wood Scott-B07421; Joerg Roedel; Yoder
Stuart-B08248
Subject: Re: [PATCH 6/6 v8] iommu/fsl: Freescale PAMU driver and IOMMU
API implementation.
On Mon, Feb 18, 2013 at 6:52 AM, Varun Sethi varun.se...@freescale.com
wrote:
[cut]
+static phys_addr_t get_phys_addr(struct fsl_dma_domain *dma_domain,
+unsigned long iova) {
+ u32 win_cnt = dma_domain-win_cnt;
+ struct dma_window *win_ptr =
+ dma_domain-win_arr[0];
+ struct iommu_domain_geometry *geom;
+
+ geom = dma_domain-iommu_domain-geometry;
+
+ if (!win_cnt || !dma_domain-geom_size) {
+ pr_err(Number of windows/geometry not configured for
the domain\n);
+ return 0;
+ }
+
+ if (win_cnt 1) {
+ u64 subwin_size;
+ unsigned long subwin_iova;
+ u32 wnd;
+
+ subwin_size = dma_domain-geom_size ilog2(win_cnt);
Could it be just geom_size / win_cnt ??
[Sethi Varun-B16395] You would run in to linking issues with respect to u64
division on 32 bit kernels.
+ subwin_iova = iova ~(subwin_size - 1);
+ wnd = (subwin_iova - geom-aperture_start)
ilog2(subwin_size);
+ win_ptr = dma_domain-win_arr[wnd];
+ }
+
+ if (win_ptr-valid)
+ return (win_ptr-paddr + (iova (win_ptr-size -
+ 1)));
+
+ return 0;
+}
+
+static int map_liodn_subwins(int liodn, struct fsl_dma_domain
+*dma_domain)
Just call it map_subwins(). They are just sub windows, not liodn sub
windows.
[Sethi Varun-B16395] This would be called per liodn.
[cut]
+static int map_liodn_win(int liodn, struct fsl_dma_domain
+*dma_domain)
Call it map_win().
[Sethi Varun-B16395] This would again be called per liodn.
On the function names-- function names are typically named
with a noun describing some object and a verb describing
the action...and sometimes a subsystem identifier:
kmem_cache + zalloc
spin + lock
I don't think inserting liodn in the function name to indicates that it
operates per liodn makes it more clear and reads a little awkward to me:
map + liodn_win
...it's almost like there is a liodn_win object.
I think plain map_win() is more clear and the function prototype makes
it pretty clear that you are operating on an liodn.
[cut]
+static bool check_pci_ctl_endpt_part(struct pci_controller *pci_ctl)
+{
+ u32 version;
+
+ /* Check the PCI controller version number by readding BRR1
register */
+ version = in_be32(pci_ctl-cfg_addr + (PCI_FSL_BRR1 2));
+ version = PCI_FSL_BRR1_VER;
+ /* If PCI controller version is = 0x204 we can partition
endpoints*/
+ if (version = 0x204)
+ return 1;
+
+ return 0;
+}
Can we just use the compatible string here to identify the different
kinds of PCI
controllers? Reading the actual device registers is ugly right now
because
you are #defining the BRR1 stuff in a generic powerpc header.
[Sethi Varun-B16395] hmmm.., I would have to check for various different
compatible strings in that
case. May be I can move the defines to a different file. What if I move them
to some other header?
Don't personally feel too strongly about version register or header...but it
should be some fsl
PCI header that you define those regs.
You'll either need to check for a hardware version number or a compatible,
so a compatible check may be just as easy...look for fsl,qoriq-pcie-v2.4?
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
-Original Message- From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru] Sent: Friday, March 01, 2013 4:07 AM To: Sethi Varun-B16395 Cc: Kumar Gala; Benjamin Herrenschmidt; io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org list; linux-ker...@vger.kernel.org list; Wood Scott-B07421; Yoder Stuart-B08248; Joerg Roedel; Paul Mackerras; David Gibson; Alex Williamson Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata. btw the device struct already has a pointer to its iommu_group, and the iommu_group struct itself has a pointer void *iommu_data which you could use for anything you want (iommu_group_get_iommudata(), iommu_group_set_iommudata()). By design you are expected to add iommu groups to a domain but not devices so I am not so sure that you really need a pointer to domain in the device struct. Well, at the lowest level the IOMMU API does attach devices to domains-- i.e. API attach_dev(). So, it seems to conceptually make sense to have a ptr from the device to the associated domain. When you implement attach_dev() you need to be able to see whether the device is already attached to a domain. Adding a couple of levels of indirection...from device to group to domain...doesn't seems to make things simpler or better IMHO. x86 keeps a pointer to the domain in device archdata and since there is a direct correlation between a device and domain I'd rather see it where this patch has it. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v2] KVM: PPC: add paravirt idle loop for 64-bit book E
-Original Message- From: Wood Scott-B07421 Sent: Thursday, January 24, 2013 12:22 PM To: Yoder Stuart-B08248 Cc: ag...@suse.de; b...@kernel.crashing.org; linuxppc-...@ozlabs.org; kvm-...@vger.kernel.org; k...@vger.kernel.org; Yoder Stuart-B08248 Subject: Re: [PATCH][v2] KVM: PPC: add paravirt idle loop for 64-bit book E On 01/22/2013 05:54:43 PM, Stuart Yoder wrote: +.macro BOOK3E_IDLE_LOOP +1: + PPC_WAIT(0) b 1b +.endm + +.macro EPAPR_EV_IDLE_LOOP +idle_loop: + LOAD_REG_IMMEDIATE(r11, EV_HCALL_TOKEN(EV_IDLE)) + +.global epapr_ev_idle_start +epapr_ev_idle_start: + li r3, -1 + nop + nop + nop + b idle_loop +.endm + +BOOK3E_IDLE epapr_ev_idle, EPAPR_EV_IDLE_LOOP + +BOOK3E_IDLE book3e_idle BOOK3E_IDLE_LOOP Why the comma after epapr_ev_idle but not after book3e_idle? Also you have spaces where there should be tabs. Otherwise looks good. Hmm...there shouldn't be a comma there. I'll respin and fix the whitespace too. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/85xx: describe the PAMU topology in the device tree
-Original Message- From: Gala Kumar-B11780 Sent: Wednesday, January 23, 2013 11:27 AM To: Wood Scott-B07421; Yoder Stuart-B08248 Cc: linuxppc-...@ozlabs.org list; Timur Tabi Subject: Re: [PATCH 2/2] powerpc/85xx: describe the PAMU topology in the device tree On Jan 17, 2013, at 4:34 PM, Timur Tabi wrote: From: Timur Tabi ti...@freescale.com The PAMU caches use the LIODNs to determine which cache lines hold the entries for the corresponding LIODs. The LIODNs must therefore be carefully assigned to avoid cache thrashing -- two active LIODs with LIODNs that put them in the same cache line. Currently, LIODNs are statically assigned by U-Boot, but this has limitations. LIODNs are assigned even for devices that may be disabled or unused by the kernel. Static assignments also do not allow for device drivers which may know which LIODs can be used simultaneously. In other words, we really should assign LIODNs dynamically in Linux. To do that, we need to describe the PAMU device and cache topologies in the device trees. Signed-off-by: Timur Tabi ti...@freescale.com --- .../devicetree/bindings/powerpc/fsl/guts.txt | 14 ++- .../devicetree/bindings/powerpc/fsl/pamu.txt | 142 arch/powerpc/boot/dts/fsl/p2041si-post.dtsi| 87 +++-- arch/powerpc/boot/dts/fsl/p3041si-post.dtsi| 87 +++-- arch/powerpc/boot/dts/fsl/p4080si-post.dtsi| 68 +- arch/powerpc/boot/dts/fsl/p5020si-post.dtsi| 92 +++-- arch/powerpc/boot/dts/fsl/p5040si-post.dtsi| 92 +++-- 7 files changed, 533 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/pamu.txt Scott, Stuart, does this have your guys Ack? Ack ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc: set stack limit properly in crit_transfer_to_handler
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Monday, July 16, 2012 3:36 PM To: Yoder Stuart-B08248 Cc: b...@kernel.crashing.org; s...@canb.auug.org.au; pau...@samba.org; linuxppc-dev@lists.ozlabs.org; ag...@suse.de Subject: Re: [PATCH] powerpc: set stack limit properly in crit_transfer_to_handler On Jul 16, 2012, at 2:06 PM, Stuart Yoder wrote: From: Stuart Yoder stuart.yo...@freescale.com without setting the stack limit like this there is the possibility of stack overflow which corrupts the thread info but is not detected by stack overflow detection Signed-off-by: Stuart Yoder stuart.yo...@freescale.com --- arch/powerpc/kernel/entry_32.S | 12 ++-- 1 files changed, 10 insertions(+), 2 deletions(-) Do we need this for debug mcheck ? Maybe... I don't know the history of this code and why this is only done in the critical exception handlers. But, this particular patch is to undo/fix something I introduced in: powerpc: Use CURRENT_THREAD_INFO instead of open coded assembly Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: linux-next: build failure after merge of the kvm-ppc tree
-Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Thursday, July 05, 2012 1:03 AM To: Stephen Rothwell Cc: linux-n...@vger.kernel.org; linux-ker...@vger.kernel.org; Yoder Stuart-B08248; ppc-dev Subject: Re: linux-next: build failure after merge of the kvm-ppc tree On 05.07.2012, at 07:49, Stephen Rothwell wrote: Hi Alexander, After merging the kvm-ppc tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: arch/powerpc/kernel/exceptions-64s.S: Assembler messages: arch/powerpc/kernel/exceptions-64s.S:479: Error: wrong number of operands arch/powerpc/kernel/exceptions-64s.S:486: Error: wrong number of operands arch/powerpc/kernel/exceptions-64s.S:486: Error: wrong number of operands arch/powerpc/kernel/exceptions-64s.S:487: Error: wrong number of operands arch/powerpc/kernel/exceptions-64s.S:487: Error: wrong number of operands arch/powerpc/kernel/exceptions-64s.S:494: Error: wrong number of operands arch/powerpc/kernel/exceptions-64s.S:494: Error: wrong number of operands Caused by commit bc8cc4993e19 (PPC: use CURRENT_THREAD_INFO instead of open coded assembly). The fact that this patch has problems was already pointed out on the linuxppc-dev mailing list and it clearly hasn't been build tested. I have used the version of the kvm-ppc tree from next-20120703 for today. Ah, yes, thanks. I kept the old, broken version in my tree to make sure I have the dependencies for (and don't forget) the (hopefully good) patches that follow on top, but was planning to replace it once we have a new version of the CURRENT_THREAD_INFO one. Stuart, could you please send a new version of the CURRENT_THREAD_INFO patch? Yes, will send that shortly. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH][v2] PPC: use CURRENT_THREAD_INFO instead of open coded assembly
-Original Message- From: Alexander Graf [mailto:ag...@suse.de] Sent: Monday, July 02, 2012 4:16 PM To: Yoder Stuart-B08248 Cc: b...@kernel.crashing.org; linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH][v2] PPC: use CURRENT_THREAD_INFO instead of open coded assembly On 02.07.2012, at 23:14, Stuart Yoder wrote: From: Stuart Yoder stuart.yo...@freescale.com Signed-off-by: Stuart Yoder stuart.yo...@freescale.com --- -this patch is a pre-requisite for the idle hcall which I am trying to get into Alex's KVM tree, so ideally would like Ben's ack and get this applied to Alex's tree -built/tested with a 32-bit booke kernel, built a 64-bit booke kernel -v2 -moved CURRENT_THREAD_INFO under assembly only #ifdef arch/powerpc/include/asm/exception-64s.h |4 ++-- arch/powerpc/include/asm/thread_info.h |8 arch/powerpc/kernel/entry_32.S | 24 arch/powerpc/kernel/entry_64.S | 14 +++--- arch/powerpc/kernel/exceptions-64e.S |2 +- arch/powerpc/kernel/exceptions-64s.S |2 +- arch/powerpc/kernel/head_fsl_booke.S |2 +- arch/powerpc/kernel/idle_6xx.S |4 ++-- arch/powerpc/kernel/idle_book3e.S|2 +- arch/powerpc/kernel/idle_e500.S |4 ++-- arch/powerpc/kernel/idle_power4.S|2 +- arch/powerpc/kernel/misc_32.S|4 ++-- arch/powerpc/kvm/bookehv_interrupts.S|6 +- arch/powerpc/mm/hash_low_32.S|8 arch/powerpc/sysdev/6xx-suspend.S|2 +- 15 files changed, 46 insertions(+), 42 deletions(-) diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h index d58fc4e..5dbd00d 100644 --- a/arch/powerpc/include/asm/exception-64s.h +++ b/arch/powerpc/include/asm/exception-64s.h @@ -293,7 +293,7 @@ label##_hv: \ #define RUNLATCH_ON \ BEGIN_FTR_SECTION \ - clrrdi r3,r1,THREAD_SHIFT; \ + CURRENT_THREAD_INFO(r3, r1) \ ld r4,TI_LOCAL_FLAGS(r3); \ andi. r0,r4,_TLF_RUNLATCH;\ beqlppc64_runlatch_on_trampoline; \ @@ -332,7 +332,7 @@ label##_common: \ #ifdef CONFIG_PPC_970_NAP #define FINISH_NAP \ BEGIN_FTR_SECTION \ - clrrdi r11,r1,THREAD_SHIFT;\ + CURRENT_THREAD_INFO(r11, r1)\ ld r9,TI_LOCAL_FLAGS(r11); \ andi. r10,r9,_TLF_NAPPING;\ bnelpower4_fixup_nap; \ diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h index 68831e9..3760620 100644 --- a/arch/powerpc/include/asm/thread_info.h +++ b/arch/powerpc/include/asm/thread_info.h @@ -74,6 +74,14 @@ static inline struct thread_info *current_thread_info(void) return (struct thread_info *)(sp ~(THREAD_SIZE-1)); } +#else + +#ifndef CONFIG_PPC64 Oh no! The logic is still backwards :( Doh...somehow I missed that comment in your previous reply. Will fix that. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: pci node question
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Friday, April 20, 2012 4:11 PM
To: Kumar Gala
Cc: Yoder Stuart-B08248; linuxppc-dev@lists.ozlabs.org
Subject: Re: pci node question
On Fri, 2012-04-20 at 13:53 -0500, Kumar Gala wrote:
On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
There was refactoring change a while back that moved
the interrupt map down into the virtual pci bridge.
example:
42 /* controller at 0x20 */
43 pci0 {
44 compatible = fsl,p2041-pcie, fsl,qoriq-pcie-v2.2;
45 device_type = pci;
46 #size-cells = 2;
47 #address-cells = 3;
48 bus-range = 0x0 0xff;
49 clock-frequency = ;
50 interrupts = 16 2 1 15;
51 pcie@0 {
52 reg = 0 0 0 0 0;
53 #interrupt-cells = 1;
54 #size-cells = 2;
55 #address-cells = 3;
56 device_type = pci;
57 interrupts = 16 2 1 15;
58 interrupt-map-mask = 0xf800 0 0 7;
59 interrupt-map =
60 /* IDSEL 0x0 */
61 0 0 1 mpic 40 1 0 0
62 0 0 2 mpic 1 1 0 0
63 0 0 3 mpic 2 1 0 0
64 0 0 4 mpic 3 1 0 0
65 ;
66 };
67 };
Why was the interrupt-map moved here?
Its been a while, but I think i moved it down because of which node is used
for interrupt handling in
linux.
Yeah, it would swizzle if going accross the virtual P2P bridge. On the
other hand, if it's PCIe, the children of the vP2P should always be at
device 0 and thus the swizzling should be a NOP no ? So we -could- leave
it in the PHB unless I'm mistaken...
On the other hand, we probably want to fix the mapping code to handle
things like SR-IOV PFs with different device numbers... do those get
swizzled ? In that case we might want to keep things down the virtual
bridge.
Do we really need the error interrupt specified twice?
I put it twice because it has multiple purposes, one has to do with
interrupts defined by the PCI spec
vs ones defined via FSL controller.
Why is there a zeroed out reg property: reg = 0 0 0 0 0 ??
scratching my head, what happens if you remove it?
If you remove it, the kernel will fail to match the vP2P with the
corresponding struct pci_dev It's not zeroed out. It contains a
valid bus/dev/fn ... of 0,0,0 :-)
Hmmm... I vaguely understand what you are saying. But why is the
length zero, that is what doesn't make sense on the surface?
We really should put a comment on that reg property-- can you suggest
a short comment that would capture what the reg with all zeros
is for? ...I'll submit a patch.
Thanks,
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: pci node question
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Monday, April 23, 2012 3:22 PM To: Yoder Stuart-B08248 Cc: Kumar Gala; linuxppc-dev@lists.ozlabs.org Subject: RE: pci node question On Mon, 2012-04-23 at 15:48 +, Yoder Stuart-B08248 wrote: Hmmm... I vaguely understand what you are saying. But why is the length zero, that is what doesn't make sense on the surface? Ah indeed, on would think that we could represent the real size of the config space there... but I've always seen this as 0 in real OF implementations as well, at least the G5 device-tree I'm looking at now has it that way. We really should put a comment on that reg property-- can you suggest a short comment that would capture what the reg with all zeros is for? ...I'll submit a patch. Hrm.. config address of the device: 0,0,0 ? How about: /* config space address of the device 0,0,0. OF convention is that the size of config space is 0. */ ...is that accurate? Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
pci node question
There was refactoring change a while back that moved
the interrupt map down into the virtual pci bridge.
example:
42 /* controller at 0x20 */
43 pci0 {
44 compatible = fsl,p2041-pcie, fsl,qoriq-pcie-v2.2;
45 device_type = pci;
46 #size-cells = 2;
47 #address-cells = 3;
48 bus-range = 0x0 0xff;
49 clock-frequency = ;
50 interrupts = 16 2 1 15;
51 pcie@0 {
52 reg = 0 0 0 0 0;
53 #interrupt-cells = 1;
54 #size-cells = 2;
55 #address-cells = 3;
56 device_type = pci;
57 interrupts = 16 2 1 15;
58 interrupt-map-mask = 0xf800 0 0 7;
59 interrupt-map =
60 /* IDSEL 0x0 */
61 0 0 1 mpic 40 1 0 0
62 0 0 2 mpic 1 1 0 0
63 0 0 3 mpic 2 1 0 0
64 0 0 4 mpic 3 1 0 0
65 ;
66 };
67 };
Why was the interrupt-map moved here?
Do we really need the error interrupt specified twice?
Why is there a zeroed out reg property: reg = 0 0 0 0 0 ??
Thanks,
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: pci node question
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Friday, April 20, 2012 1:54 PM
To: Yoder Stuart-B08248
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: pci node question
On Apr 20, 2012, at 1:37 PM, Yoder Stuart-B08248 wrote:
There was refactoring change a while back that moved
the interrupt map down into the virtual pci bridge.
example:
42 /* controller at 0x20 */
43 pci0 {
44 compatible = fsl,p2041-pcie, fsl,qoriq-pcie-v2.2;
45 device_type = pci;
46 #size-cells = 2;
47 #address-cells = 3;
48 bus-range = 0x0 0xff;
49 clock-frequency = ;
50 interrupts = 16 2 1 15;
51 pcie@0 {
52 reg = 0 0 0 0 0;
53 #interrupt-cells = 1;
54 #size-cells = 2;
55 #address-cells = 3;
56 device_type = pci;
57 interrupts = 16 2 1 15;
58 interrupt-map-mask = 0xf800 0 0 7;
59 interrupt-map =
60 /* IDSEL 0x0 */
61 0 0 1 mpic 40 1 0 0
62 0 0 2 mpic 1 1 0 0
63 0 0 3 mpic 2 1 0 0
64 0 0 4 mpic 3 1 0 0
65 ;
66 };
67 };
Why was the interrupt-map moved here?
Its been a while, but I think i moved it down because of which node is used
for interrupt handling in
linux.
Do we really need the error interrupt specified twice?
I put it twice because it has multiple purposes, one has to do with
interrupts defined by the PCI spec
vs ones defined via FSL controller.
Why is there a zeroed out reg property: reg = 0 0 0 0 0 ??
scratching my head, what happens if you remove it?
Tried removing the zeroed reg, and get this error when bringing
up an e1000 interface:
[root@kvmtst1 root]# ifconfig eth0 192.168.1.20
e1000e :01:00.0: eth0: Unable to allocate interrupt, Error: -22
SIOCSIFFLAGS: Invalid argument
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding
-Original Message- From: Wood Scott-B07421 Sent: Friday, February 17, 2012 6:48 PM To: Yoder Stuart-B08248 Cc: Jia Hongtao-B38951; linuxppc-dev@lists.ozlabs.org; meador_i...@mentor.com; Li Yang-R58472 Subject: Re: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding On 02/17/2012 09:50 AM, Yoder Stuart-B08248 wrote: -Original Message- From: linuxppc-release-boun...@linux.freescale.net [mailto:linuxppc-release- boun...@linux.freescale.net] On Behalf Of Jia Hongtao-B38951 Sent: Thursday, February 16, 2012 8:49 PM To: linuxppc-dev@lists.ozlabs.org Cc: meador_i...@mentor.com; Li Yang-R58472; Jia Hongtao-B38951 Subject: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding This binding documents how the message register blocks found in some FSL MPIC implementations shall be represented in a device tree. Signed-off-by: Meador Inge meador_i...@mentor.com Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt new file mode 100644 index 000..b4ae70e --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt @@ -0,0 +1,62 @@ +* FSL MPIC Message Registers + +This binding specifies what properties must be available in the +device tree representation of the message register blocks found in +some FSL MPIC implementations. + +Required properties: + +- compatible: Specifies the compatibility list for the message register + block. The type shall be string and the value shall be of the form + fsl,mpic-vversion-msgr, where version is the version number of + the MPIC containing the message registers. The type for compatibles is a string-list. +- reg: Specifies the base physical address(s) and size(s) of the + message register block's addressable register space. The type shall be + prop-encoded-array. + +- interrupts: Specifies a list of interrupt source and level-sense pairs. + The type shall be prop-encoded-array. The length shall be equal to + the number of registers that are available for receiving interrupts. How many interrupts are there? If more than 1, this is where you need to specify what each interrupt is for. They aren't for anything in particular -- each interrupt is associated with a message register. The binding does say that the number of interrupts corresponds to the bits set in the receive mask. Then make that clear, it also should use the term 'interrupt-specifier' not 'interrupt source and level-sense pairs', which implies a particular parent interrupt controller configuration. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding
-Original Message- From: linuxppc-release-boun...@linux.freescale.net [mailto:linuxppc-release- boun...@linux.freescale.net] On Behalf Of Jia Hongtao-B38951 Sent: Thursday, February 16, 2012 8:49 PM To: linuxppc-dev@lists.ozlabs.org Cc: meador_i...@mentor.com; Li Yang-R58472; Jia Hongtao-B38951 Subject: [linuxppc-release] [PATCH 1/2] powerpc: document the FSL MPIC message register binding This binding documents how the message register blocks found in some FSL MPIC implementations shall be represented in a device tree. Signed-off-by: Meador Inge meador_i...@mentor.com Signed-off-by: Jia Hongtao b38...@freescale.com Signed-off-by: Li Yang le...@freescale.com --- .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 62 1 files changed, 62 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt new file mode 100644 index 000..b4ae70e --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt @@ -0,0 +1,62 @@ +* FSL MPIC Message Registers + +This binding specifies what properties must be available in the device +tree representation of the message register blocks found in some FSL +MPIC implementations. + +Required properties: + +- compatible: Specifies the compatibility list for the message register + block. The type shall be string and the value shall be of the form + fsl,mpic-vversion-msgr, where version is the version number of + the MPIC containing the message registers. The type for compatibles is a string-list. +- reg: Specifies the base physical address(s) and size(s) of the + message register block's addressable register space. The type shall be + prop-encoded-array. + +- interrupts: Specifies a list of interrupt source and level-sense pairs. + The type shall be prop-encoded-array. The length shall be equal to + the number of registers that are available for receiving interrupts. How many interrupts are there? If more than 1, this is where you need to specify what each interrupt is for. +Optional properties: + +- mpic-msgr-receive-mask: Specifies what registers in the containing block + are allowed to receive interrupts. The value is a bit mask where a set + bit at bit 'n' indicates that message register 'n' can receive interrupts. + The type shall be prop-encoded-array. If not present, then all of + the message registers in the block are available. Your example implies that this is 1 32-bit cell. If that is the case then this really should be of type 'u32'. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
-Original Message- From: Wood Scott-B07421 Sent: Monday, July 11, 2011 4:07 PM To: Yoder Stuart-B08248 Cc: Wood Scott-B07421; Tabi Timur-B04825; Grant Likely; Benjamin Herrenschmidt; Gala Kumar- B11780; Alexander Graf; linuxppc-...@ozlabs.org Subject: Re: RFC: top level compatibles for virtual platforms On Mon, 11 Jul 2011 15:41:35 -0500 Yoder Stuart-B08248 b08...@freescale.com wrote: -Original Message- From: Wood Scott-B07421 Sent: Monday, July 11, 2011 1:05 PM Just because Linux does it that way now doesn't mean it needs to. The interrupt controller has a compatible property. Match on it like any other device. You can find which one is the root interrupt controller by looking for nodes with the interrupt-controller property that doesn't have an explicit interrupt-parent (or an interrupts property? seems to be a conflict between ePAPR and the original interrupt mapping document). This may be the right long term thing to do, but restructuring how Linux powerpc platforms work is a bigger effort. I was looking for an incremental improvement over what we do now, which is pass a compatible of MPC8544DS and P4080DS for these virtual platforms. A hack is usually easier than doing it right. :-) Though often the effort required for the latter is overstated, and the right long term thing never makes the jump to short term plan. There are a few things that need to be driven off the device tree that currently aren't -- using some mechanism other than the standard device model, if necessary (or as a first step) - - and then we need a does-nothing default platform as the match of last resort. However, they _are_ compatible with MPC8544DS and P4080DS so maybe leaving the compatible string alone is ok for now. The virtual platforms are not compatible with MPC8544DS or P4080DS. Only a subset of what is on those boards is provided. And in the case of direct device assignment, often the things that are present are incompatible (e.g. different type of eTSEC). Hmm. Perhaps what we need is a real binding that defines specifically what those compatibles mean. While not identical, a KVM virtual machine is compatible in certain areas with those boards. The ePAPR defines the top level compatible as: Specifies a list of platform architectures with which this platform is compatible. This property can be used by operating systems in selecting platform specific code. 1275 doesn't mention compatible on the root from what I can see. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
-Original Message- From: Tabi Timur-B04825 Sent: Friday, July 08, 2011 8:39 PM To: Yoder Stuart-B08248 Cc: Grant Likely; Benjamin Herrenschmidt; Gala Kumar-B11780; Wood Scott-B07421; Alexander Graf; linuxppc-...@ozlabs.org Subject: Re: RFC: top level compatibles for virtual platforms On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 b08...@freescale.com wrote: MPC85xxDS - for a virtual machine for the e500v2 type platforms and would support 85xx targets, plus P2020, P1022,etc corenet-32-ds - for a virtual machine similar to the 32-bit P4080 platforms corenet-64-ds - for a virtual machine based on a 64-bit corenet platform I think we should drop the DS because that's a name applied to certain Freescale reference boards. Is being a CoreNet board really something meaningful with respect to KVM? I don't see the connection. We're talking about what would be meaningful to Linux as a guest on this platform here-- Corenet-based SoCs are similar in various ways, like using msgsnd for IPIs, having external proxy support, etc. A corenet platform created by a QEMU/KVM looks similar to other corenet SoCs. So, I'm trying to find some generic compatible string that describes this platform. Also, if these are KVM creations, shouldn't there be a kvm in the compatible string somewhere? There is nothing KVM specific about these platforms. Any hypervisor could create a similar virtual machine. A guest OS can determine specific info about the hypervisor it is running on by looking at the /hypervisor node on the device tree. We could put a generic -hv extension to indicate that this is a virtual platform. mpc85xx-hv corenet-32-hv corenet-64-hv Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
-Original Message- From: glik...@secretlab.ca [mailto:glik...@secretlab.ca] On Behalf Of Grant Likely Sent: Friday, July 08, 2011 9:42 PM To: Tabi Timur-B04825 Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala Kumar-B11780; Wood Scott- B07421; Alexander Graf; linuxppc-...@ozlabs.org Subject: Re: RFC: top level compatibles for virtual platforms On Friday, July 8, 2011, Tabi Timur-B04825 b04...@freescale.com wrote: On Fri, Jul 8, 2011 at 1:43 PM, Yoder Stuart-B08248 b08...@freescale.com wrote: MPC85xxDS - for a virtual machine for the e500v2 type platforms and would support 85xx targets, plus P2020, P1022,etc corenet-32-ds - for a virtual machine similar to the 32-bit P4080 platforms corenet-64-ds - for a virtual machine based on a 64-bit corenet platform I think we should drop the DS because that's a name applied to certain Freescale reference boards. Is being a CoreNet board really something meaningful with respect to KVM? I don't see the connection. Also, if these are KVM creations, shouldn't there be a kvm in the compatible string somewhere? I would say so. That would accurately describe the execution environment. As I mentioned to Timur, there is nothing KVM specific about the execution environment. The /hypervisor node (as per ePAPR 1.1) describes hypervisor specific info. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
-Original Message-
From: Wood Scott-B07421
Sent: Monday, July 11, 2011 11:24 AM
To: Tabi Timur-B04825
Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala
Kumar-B11780; Wood Scott-
B07421; Alexander Graf; linuxppc-...@ozlabs.org
Subject: Re: RFC: top level compatibles for virtual platforms
On Mon, 11 Jul 2011 10:45:47 -0500
Timur Tabi ti...@freescale.com wrote:
Also, if these are KVM creations, shouldn't there be a kvm in the
compatible string somewhere?
There is nothing KVM specific about these platforms. Any hypervisor
could create a similar virtual machine.
True, but I think we're on a slippery slope, here. Virtualization
allows us to create virtual platforms that are not well defined.
Linux requires a unique compatible string for each platform.
The device tree is supposed to describe the hardware (virtual or otherwise),
not just supply
what Linux wants. Perhaps there simply shouldn't be a toplevel compatible if
there's nothing
appropriate to describe there -- and fix whatever issues Linux has with that.
But there is a concept in Linux of a platform 'machine':
define_machine(p4080_ds) {
.name = P4080 DS,
.probe = p4080_ds_probe,
.setup_arch = corenet_ds_setup_arch,
.init_IRQ = corenet_ds_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
#endif
.get_irq= mpic_get_coreint_irq,
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
Right now p4080_ds_probe needs something to match on to determine
whether this is the machine type. How would it work if
there was no top level compatible to match on? Some
platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(),
others need corenet_ds_pic_init(). We need a way to
select the machine.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: RFC: top level compatibles for virtual platforms
-Original Message-
From: Wood Scott-B07421
Sent: Monday, July 11, 2011 1:05 PM
To: Yoder Stuart-B08248
Cc: Wood Scott-B07421; Tabi Timur-B04825; Grant Likely; Benjamin
Herrenschmidt; Gala Kumar-
B11780; Alexander Graf; linuxppc-...@ozlabs.org
Subject: Re: RFC: top level compatibles for virtual platforms
On Mon, 11 Jul 2011 12:41:20 -0500
Yoder Stuart-B08248 b08...@freescale.com wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Monday, July 11, 2011 11:24 AM
To: Tabi Timur-B04825
Cc: Yoder Stuart-B08248; Grant Likely; Benjamin Herrenschmidt; Gala
Kumar-B11780; Wood Scott- B07421; Alexander Graf;
linuxppc-...@ozlabs.org
Subject: Re: RFC: top level compatibles for virtual platforms
On Mon, 11 Jul 2011 10:45:47 -0500
Timur Tabi ti...@freescale.com wrote:
Also, if these are KVM creations, shouldn't there be a kvm in
the compatible string somewhere?
There is nothing KVM specific about these platforms. Any
hypervisor could create a similar virtual machine.
True, but I think we're on a slippery slope, here. Virtualization
allows us to create virtual platforms that are not well defined.
Linux requires a unique compatible string for each platform.
The device tree is supposed to describe the hardware (virtual or
otherwise), not just supply what Linux wants. Perhaps there simply
shouldn't be a toplevel compatible if there's nothing appropriate to
describe there -- and
fix whatever issues Linux has with that.
But there is a concept in Linux of a platform 'machine':
So have a Linux machine that is used when no other one matches. That
doesn't justify making
something up in the device tree.
define_machine(p4080_ds) {
.name = P4080 DS,
.probe = p4080_ds_probe,
.setup_arch = corenet_ds_setup_arch,
.init_IRQ = corenet_ds_pic_init,
#ifdef CONFIG_PCI
.pcibios_fixup_bus = fsl_pcibios_fixup_bus,
#endif
.get_irq= mpic_get_coreint_irq,
.restart= fsl_rstcr_restart,
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
};
Right now p4080_ds_probe needs something to match on to determine
whether this is the machine type. How would it work if
there was no top level compatible to match on? Some
platforms (e.g. e500v2-type) need mpc85xx_ds_pic_init(), others need
corenet_ds_pic_init().
Just because Linux does it that way now doesn't mean it needs to. The
interrupt controller
has a compatible property. Match on it like any other device. You can find
which one is the
root interrupt controller by looking for nodes with the interrupt-controller
property that
doesn't have an explicit interrupt-parent (or an interrupts property? seems
to be a conflict
between ePAPR and the original interrupt mapping document).
This may be the right long term thing to do, but restructuring
how Linux powerpc platforms work is a bigger effort. I was looking
for an incremental improvement over what we do now, which is pass
a compatible of MPC8544DS and P4080DS for these virtual platforms.
However, they _are_ compatible with MPC8544DS and P4080DS so maybe
leaving the compatible string alone is ok for now.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RFC: top level compatibles for virtual platforms
With KVM on Freescale booke parts we have currently two general types of virtual platforms-- 1) an 85xx-like platform with e500v2 cpus, etc, and 2) a P4080-like platform with a corenet based bus. Today QEMU passes through to the guest a device tree with a top level compatible of either MPC8544DS, or fsl,P4080DS. These work but neither is quite accurate this is used on all targets regardless of the underlying physical hardware. Also, the guest device tree represents virtual devices as well as a subset of the cpus, memory, and devices on the hardware platform. So continuing to use MPC8544DS or fsl,P4080DS compatible for all QEMU/KVM created virtual machines is misleading and seems hackish. They are compatible to a degree, but the virtual platform would typically be quite different. What do you all think about creating some new somewhat generic machine types in Linux to represent these 2 types of virtual platforms. Perhaps: MPC85xxDS - for a virtual machine for the e500v2 type platforms and would support 85xx targets, plus P2020, P1022,etc corenet-32-ds - for a virtual machine similar to the 32-bit P4080 platforms corenet-64-ds - for a virtual machine based on a 64-bit corenet platform Thoughts? Thanks, Stuart Yoder ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 0/4] powerpc: Open PIC binding and pic-no-reset
-Original Message- From: Meador Inge [mailto:mead...@gmail.com] Sent: Thursday, February 10, 2011 9:26 PM To: Benjamin Herrenschmidt Cc: Yoder Stuart-B08248; devicetree-disc...@lists.ozlabs.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v3 0/4] powerpc: Open PIC binding and pic-no-reset Apologies for the bad post. Bad day for email ... Please ignore the top reply in my previous reply. The full reply is the below the quote. On Thu, Feb 10, 2011 at 8:01 PM, Meador Inge meador_i...@mentor.com wrote: On 02/10/2011 02:42 PM, Meador Inge wrote: -- Forwarded message -- From: Meador Ingemeador_i...@mentor.com Date: Fri, Feb 4, 2011 at 5:25 PM Subject: [PATCH v3 0/4] powerpc: Open PIC binding and pic-no-reset To: linuxppc-dev@lists.ozlabs.org Cc: devicetree-disc...@lists.ozlabs.org, Hollis Blanchard hollis_blanch...@mentor.com This patch set provides a binding for Open PIC and implements support for a new property, specified by that binding, called pic-no-reset. With pic-no-reset in place the protected-sources property is no longer needed and its full implementation was removed. protected-sources is still checked for, however, for legacy purposes. For v3 of this patch the Open PIC binding was changed to be more consistent with existing bindings, several DTS files were cleaned up, no-reset was changed to pic-no-reset, and a check to treat protected-sources as a synonym for pic-no-reset was added. From the feedback I have received so far, the fundamental ideas in this patch set are sane. However, the following issues still need agreement: 1. What should be the name of the no reset property? pic-no-reset or no-reset? 2. Should we just keep the existing protected sources implementation in place? For (1), I prefer no-reset. I also prefer plain no-reset. The property is on a pic node so pic on the property seems redundant. For (2), I still think that we can make no- reset a synonym for protected-sources and that things will work out. Ben, you said that you would really like to leave the protected sources implementation alone. Is the mechanism implemented in PATCH v3 3/4 [1] of having protected-sources as a synonym for pic-no-reset not suitable? I thought what Ben was getting at was that there is existing firmware that may provide a device tree with protected-sources, and thus we should continue supporting it for backwards compatibility. So, I would say add no-reset as the preferred mechanism going forward, but keep protected-sources for backwards compatibility. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v3 1/4] powerpc: Removing support for 'protected-sources'
-Original Message- From: devicetree-discuss- bounces+stuart.yoder=freescale@lists.ozlabs.org [mailto:devicetree- discuss-bounces+stuart.yoder=freescale@lists.ozlabs.org] On Behalf Of Benjamin Herrenschmidt Sent: Monday, February 07, 2011 3:46 PM To: Meador Inge Cc: Hollis Blanchard; devicetree-disc...@lists.ozlabs.org; linuxppc- d...@lists.ozlabs.org Subject: Re: [PATCH v3 1/4] powerpc: Removing support for 'protected- sources' In my previous reply I said that it is not so much as a need as it is a potential simplification. After further reflection, I don't think that is completely true. As we get into AMP systems with higher core counts, then implementing this functionality using the existing protected-sources implementation versus the new pic-no-reset work is going to be harder to maintain. I'm not arguing that your approach isn't more suitable for AMP systems, I just want to leave the existing protected-sources mechanism alone. I'm not opposing adding a new, better, mechanism for newer platforms. However, I'd name it differently. pic-no-reset doesn't carry enough meaning in that case. What we want to point out here is that the PIC has been pre-initialized. Another option, which may be cleaner, is to stick to no-reset (no need for pic- prefix) and make it do just that (prevent the reset), and then use a positive variant of protected-sources, call it allowed-sources. Maybe even make it a series of ranges. Then have the MPIC only access these. I think this is more robust as it would also prevent accidental use of the wrong sources (bad device-tree, drivers that let you muck around with irq numbers, etc...). What is the use case for allowed-sources? For AMP the only device nodes in your device tree should be your AMP partition's devices, thus any interrupt specifiers in your dev tree are allowed. The MPIC is a shared device and thus the need for no-reset. So, all newer platforms should need is no-reset. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH v2 2/3] powerpc: document the Open PIC device tree binding
+ - no-reset + Usage: optional + Value type: empty + Definition: The presence of this property indicates that the + PIC + should not be reset during runtime initialization. The + presence of + this property also mandates that any initialization related + to + interrupt sources shall be limited to sources explicitly + referenced + in the device tree. Please follow the lead set by the other binding documentation which is more concise and tends to be of the form: Required properties: - reg : description - interrupt-controller : description Optional Properties: - no-reset : blah I'm considering formalizing the binding format so that fully specified and cross-referenced documentation can be generated from the bindings directory. Regarding the format-- The definition should also to specify the value type. I don't see this being consistently done in existing bindings. They are not completely unclear, but using consistent terms might help. The ePAPR uses this convention: empty # no value, a Boolean u32 # A 32-bit integer in big-endian format u64 # A 64-bit integer in big-endian format string # null terminated prop-encoded-array# format specific to the property phandle# A u32 value, referecnes another node stringlist# A list of string values concatenated together. The identifier prop-encoded-array came from precedence in other of binding and ieee1275. prop-encoded-arrays should be be specifically defined in terms of # of cells and the meaning of each cell. If you use the above types identifiers, there is no ambiguity. Also, there are properties that don't necessarily fall in 'required' and 'optional', but may be required depending on the context. Thus the 'Usage' identifier which Meador derived from my mpic binding posted. Usage could be: Required Optional See Definition Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: document the MPIC device tree binding
-Original Message- From: Meador Inge [mailto:meador_i...@mentor.com] Sent: Wednesday, January 19, 2011 6:08 PM To: Yoder Stuart-B08248 Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; devicetree- disc...@lists.ozlabs.org; Blanchard, Hollis Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding On 01/19/2011 04:14 PM, Yoder Stuart-B08248 wrote: +** Optional properties: + + - no-reset : The presence of this property indicates that the MPIC +should not be reset during runtime initialization. + - protected-sources : Specifies a list of interrupt sources that + are not + available for use and whose corresponding + vectors + should not be initialized. A typical use + case for + this property is in AMP systems where multiple + independent operating systems need to share + the MPIC + without clobbering each other. Is protected-sources really needed for AMP systems to tell the OSes not to clobber each other? Won't each OS be given a device tree with only its interrupt sources? ...so you know what you are allowed to touch. This was discussed a little bit already [1, 2]. The MPIC driver currently initializes the VECPRI register for all interrupt sources, which can lead to the aforementioned clobbering. For sources that are protected and not to be touched, it seems that the other need is for the OS to know (be guaranteed?) that those sources have been put in state where the source is masked or directed to other cores. You can't have interrupts occurring on sources that you are not allowed to initialize. So the no-reset property could potentially cover this as well-- if it was defined to mean don't reset the mpic and boot firmware has put all sources in a sane initial state. And we wouldn't need the protected-sources property any longer. Stuart Right...so it would seem that the no-reset property if prop ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: document the MPIC device tree binding
-Original Message- From: Meador Inge [mailto:meador_i...@mentor.com] Sent: Wednesday, January 19, 2011 2:25 PM To: Yoder Stuart-B08248 Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org; Blanchard, Hollis Subject: Re: [PATCH 1/2] powerpc: document the MPIC device tree binding On 01/18/2011 02:21 PM, Yoder Stuart-B08248 wrote: Documentation/powerpc/dts-bindings/mpic.txt | 78 This is really the binding for an open-pic interrupt controller and I think the name should reflect that-- open-pic.txt. Yup, agreed. +This binding specifies what properties and child nodes must be +available on the device tree representation of the MPIC interrupt +controller. This binding is based on the binding defined for Open +PIC in [1] and is a superset of that binding. I think it would be better to base this on the ePAPR binding which was based on the original chrp binding. Properties like name and device_type are deprecated not being used in flat device trees. http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pd f The proposed new properties really should go back into the ePAPR. I read portions of ePAPR while writing this binding and considered that. My only worry was that ePAPR is focused on embedded systems and this binding will have to cover non-embedded systems that exist in the kernel. However, perhaps that is not a legitimate concern? The ePAPR tried to codify what was previously implemented in Linux, so I don't think lack of things like name and device_type in the binding are an issue. + +** Required properties: + + NOTE: Many of these descriptions were paraphrased from [1] to aid + readability. + + - name : Specifies the name of the MPIC. Drop this. No DTS files use it. Done. + - device_type : Specifies the device type of this MPIC. The + value of this + property shall be open-pic. device_type is deprecated, since this is not real open-firmware. In practice the kernel is matching on device_type, but we want to move away from that to match on compatible, just hasn't been implemented yet. I will drop this property with the expectation that the kernel will be fixed. From a quick grep of '.../arch/powerpc' it looks like most uses are of the form: np = of_find_node_by_type(NULL, open-pic); if (np == NULL) return; In most of these cases I suppose the 'of_find_node_by_type' calls could just be replaced with calls to 'of_find_compatible_node(NULL, open-pic)'. For backwards compatibility, we should continue to accept the old/deprecated device_type=open-pic, but in addition we should accept the compatible=open-pic. + - reg : Specifies the base physical address(s) and size(s) of this + MPIC's + addressable register space. + - compatible : Specifies the compatibility list for the MPIC. The + property + value shall include chrp,open-pic. In the ePAPR we modified this to just open-pic, because this has nothing to do with chrp anymore. I think just open-pic is what we want. OK, but as a migration path we should allow the kernel to accept both (Scott mentioned this in another reply), but open-pic is the documented correct way. Right. + - interrupt-controller : The presence of this property identifies + the node +as a MPIC. No property value should be defined. + - #address-cells : Specifies the number of cells needed to encode an + address. The value of this property shall always + be 0 + so that 'interrupt-map' nodes do not have to + specify a + parent unit address. + - #interrupt-cells : Specifies the number of cells needed to encode + an +interrupt source. Should be 2, correct? Yup. +** Optional properties: + + - no-reset : The presence of this property indicates that the MPIC +should not be reset during runtime initialization. + - protected-sources : Specifies a list of interrupt sources that are + not + available for use and whose corresponding + vectors + should not be initialized. A typical use case + for + this property is in AMP systems where multiple + independent operating systems need to share + the MPIC + without clobbering each other. I do think you need to include the definition of interrupt specifiers here. Feel free to cut/paste text from my Freescale mpic binding. OK, I will look into that. Thanks. I have a version 2 I hope to send out later today. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: document the MPIC device tree binding
+** Optional properties: + + - no-reset : The presence of this property indicates that the MPIC + should not be reset during runtime initialization. + - protected-sources : Specifies a list of interrupt sources that are + not + available for use and whose corresponding + vectors + should not be initialized. A typical use case + for + this property is in AMP systems where multiple + independent operating systems need to share + the MPIC + without clobbering each other. Is protected-sources really needed for AMP systems to tell the OSes not to clobber each other? Won't each OS be given a device tree with only its interrupt sources? ...so you know what you are allowed to touch. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] define binding for fsl mpic interrupt controllers
-Original Message- From: Meador Inge [mailto:meador_i...@mentor.com] Sent: Monday, January 17, 2011 7:21 PM To: Yoder Stuart-B08248 Cc: linuxppc-dev@lists.ozlabs.org; devicetree-disc...@lists.ozlabs.org; Blanchard, Hollis; Meador Inge Subject: Re: [PATCH] define binding for fsl mpic interrupt controllers Hi Stuart, From: Stuart Yoderstuart.yo...@freescale.com define the binding for compatible = fsl,mpic, including the definition of 4-cell interrupt specifiers. The 3rd and 4th cells are needed to define additional types of interrupt source outside the normal external and internal interrupts in FSL SoCs. Define error interrupt, IPIs, and PIC timer sources. Recently I posted an RFC concerning a binding for the MPIC [1]. I also submitted a patch based on that feedback today (patch subject '[PATCH 1/2] powerpc: document the MPIC device tree binding'). You provide much more information concerning the interrupt sources and how interrupt specifiers are encoded. I had a few more properties listed: 'name', 'device_type', 'protected-sources', and 'no-reset'. The 'no-reset' property is a proposed addition to the binding, the others are already in use. I'm not sure a complete merge into one binding makes sense. The thing that motivated creating this new binding with 4 cells was a thread from last year. See: http://lists.ozlabs.org/pipermail/devicetree-discuss/2010-January/001489.html Since Freescale had the need to represent additional information in interrupt specifiers (error ints, timers, ipis), the suggestion at the end was to add additional cells in a FSL-specific binding. So this really is a Freescale specific thing and does belong in the Freescale binding directory. That being said, if there is consensus on the AMP related properties, I should probably incorporate those as well-- protected-sources and no-reset. I'll separately comment on your mpic binding patch. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 1/2] powerpc: document the MPIC device tree binding
From: Meador Inge meador_i...@mentor.com Date: Mon, Jan 17, 2011 at 6:52 PM Subject: [PATCH 1/2] powerpc: document the MPIC device tree binding To: linuxppc-dev@lists.ozlabs.org Cc: minge meador_i...@mentor.com, devicetree-disc...@lists.ozlabs.org, Blanchard, Hollis hollis_blanch...@mentor.com This binding documents several properties that have been in use for quite some time, and adds one new property 'no-reset', which controls whether the MPIC should be reset during runtime initialization. Signed-off-by: Meador Inge meador_i...@mentor.com CC: Hollis Blanchard hollis_blanch...@mentor.com --- Documentation/powerpc/dts-bindings/mpic.txt | 78 This is really the binding for an open-pic interrupt controller and I think the name should reflect that-- open-pic.txt. +++ 1 files changed, 78 insertions(+), 0 deletions(-) create mode 100644 Documentation/powerpc/dts-bindings/mpic.txt diff --git a/Documentation/powerpc/dts-bindings/mpic.txt b/Documentation/powerpc/dts-bindings/mpic.txt new file mode 100644 index 000..3a67919 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/mpic.txt @@ -0,0 +1,78 @@ +* MPIC Binding + +This binding specifies what properties and child nodes must be +available on the device tree representation of the MPIC interrupt +controller. This binding is based on the binding defined for Open PIC +in [1] and is a superset of that binding. I think it would be better to base this on the ePAPR binding which was based on the original chrp binding. Properties like name and device_type are deprecated not being used in flat device trees. http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf The proposed new properties really should go back into the ePAPR. + +** Required properties: + + NOTE: Many of these descriptions were paraphrased from [1] to aid + readability. + + - name : Specifies the name of the MPIC. Drop this. No DTS files use it. + - device_type : Specifies the device type of this MPIC. The value + of this + property shall be open-pic. device_type is deprecated, since this is not real open-firmware. In practice the kernel is matching on device_type, but we want to move away from that to match on compatible, just hasn't been implemented yet. + - reg : Specifies the base physical address(s) and size(s) of this + MPIC's + addressable register space. + - compatible : Specifies the compatibility list for the MPIC. The + property + value shall include chrp,open-pic. In the ePAPR we modified this to just open-pic, because this has nothing to do with chrp anymore. I think just open-pic is what we want. + - interrupt-controller : The presence of this property identifies + the node + as a MPIC. No property value should be defined. + - #address-cells : Specifies the number of cells needed to encode an + address. The value of this property shall always + be 0 + so that 'interrupt-map' nodes do not have to + specify a + parent unit address. + - #interrupt-cells : Specifies the number of cells needed to encode + an + interrupt source. Should be 2, correct? +** Optional properties: + + - no-reset : The presence of this property indicates that the MPIC + should not be reset during runtime initialization. + - protected-sources : Specifies a list of interrupt sources that are + not + available for use and whose corresponding + vectors + should not be initialized. A typical use case + for + this property is in AMP systems where multiple + independent operating systems need to share + the MPIC + without clobbering each other. I do think you need to include the definition of interrupt specifiers here. Feel free to cut/paste text from my Freescale mpic binding. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 0/3]: Sparc OF I2C support.
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mitch Bradley Sent: Friday, August 22, 2008 12:19 AM To: David Miller Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Wood Scott Subject: Re: [PATCH 0/3]: Sparc OF I2C support. David Miller wrote: From: Grant Likely [EMAIL PROTECTED] Date: Thu, 21 Aug 2008 22:34:31 -0600 On Thu, Aug 21, 2008 at 10:30 PM, Grant Likely [EMAIL PROTECTED] wrote: On Thu, Aug 21, 2008 at 10:29 PM, Mitch Bradley [EMAIL PROTECTED] wrote: Hi, I wrote most of 1275. Mitch Bradley ([EMAIL PROTECTED]) Hi Mitch, What is your suggestion. Where should we be discussing new device tree bindings? Whether it be real Open Firmware, or flattened device tree, or something in between ...and along those lines: is there a place for documenting new bindings? Lacking anything better, those of us in PowerPC-Linux-land have been adding documentation to Documentation/powerpc/dts-bindings/* in the Linux kernel tree. In a discussion I am having with Greg Onufer, David K. and Tayfun at Sun, Greg said the some of the newer binding documents are being published on the opensolaris site, and he is trying to get some of the older cases (like this I2C one) published there too. This collection of mailing lists is as good a place as any to discuss new bindings. I don't know how many Sun people are on the lists, but we might be able to persuade various Sun people to lurk on one or more of them; I lurk on devicetree-discuss. The opensolaris site seems as good as anywhere for publishing the bindings, especially if they can pull over the old ones from e.g. playground.sun.com . Another possible site might be openbios.org . I agree that the linuxppc-dev and devicetree-discuss mailing lists are probably the best place to discuss bindings. (I'm not aware of other good options). Once there is consensus as to what a binding should be, and publishing is needed-- for general, common bindings some single place is needed. Something that is ideally authoritative, with a committed organization behind it. One suggestion would be the power.org and follow on versions of the ePAPR. ePAPR 1.0 is out now and currently is a base document-- defines the flat device tree concept, and basically extracts the relevant parts of 1275 for how this is used in the embedded space. There are a few bindings specified in the ePAPR, based on the old Open Firmware working group stuff: -cpu -interrupt controllers -PCI -network devices -DCR devices -serial devices ePAPR doc is at: http://www.power.org/resources/downloads/ It's obvious that more bindings are needed, and the expecation from those who worked on the ePAPR (most or all of which are on this mailing list) was that as bindings are codified they could be added to the ePAPR. The best way to publish bindings will be on the web. I've been looking into getting power.org to host a wiki-based site that could be used as a repository for bindings. We could have both an area for general bindings and company specific ones. I've made some progress here and actually have a sandbox wiki that I'm playing with. Stuart Yoder Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Gibson Sent: Thursday, August 07, 2008 1:13 AM To: Tabi Timur Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [RFC/PATCH 2/3] of: add of_lookup_stdout() utility function On Wed, Aug 06, 2008 at 11:46:47AM -0500, Timur Tabi wrote: On Wed, Aug 6, 2008 at 1:02 AM, Grant Likely [EMAIL PROTECTED] wrote: From: Grant Likely [EMAIL PROTECTED] of_lookup_stdout() is useful for figuring out what device to use as output for early boot progress messages. It returns the node pointed to by the linux,stdout-path property in the chosen node. I thought linux,stdout-path is deprecated are we're supposed to be using the aliases node instead? During the ePAPR process this idea came up - standardising a 'stdout' alias that would replace linux,stdout-path in chosen. However that was done in ignorance of the history of the linux,stdout-path property and its connection to the stdout ihandle in chosen. In any case, the proposed 'stdout' alias didn't make the final cut for ePAPR, so how to address this for flat-tree systems is still an open question. In the ePAPR discussion I think we generally agreed that an alias was better than a property under /chosen. There were 2 things that caused us to delete the /aliases/stdout. One was discussions around whether we needed to support multiple consoles somehow. The second was the idea that we may need a /aliases/stdin as well. You could conceptually have stdout be a monitor and a stdin be a keyboard. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ePAPR 1.0 is published
The ePAPR 1.0 spec is officially published and available on the power.org website. http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf One purpose of the spec is to more formally specify in one place the flat device tree concept defined booting_without_of.txt plus the relevant parts of 1275 and misc bindings created by the OF working group. It also contains a specification for how multicore boot works in an ePAPR-compliant system. Stuart Yoder Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Add some documentation for the dts formta
Signed-off-by: Stuart Yoder [EMAIL PROTECTED]
-Original Message-
From: David Gibson [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2008 6:47 PM
To: Loeliger Jon
Cc: Yoder Stuart; linuxppc-dev@ozlabs.org
Subject: dtc: Add some documentation for the dts formta
This patch adds a dts-format.txt in the Documentation directory, with
an introduction to the dtc source format. Note that this
documentation is also going into the upcoming ePAPR specification.
Signed-off-by: David Gibson [EMAIL PROTECTED]
---
Documentation/dts-format.txt | 110
+++
1 file changed, 110 insertions(+)
I wrote this documentation based on an earlier draft from Stuart
Yoder. Stuart, can you please reply with a Signed-off-by line?
Index: dtc/Documentation/dts-format.txt
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/Documentation/dts-format.txt 2008-03-11
10:42:17.0 +1100
@@ -0,0 +1,110 @@
+Device Tree Source Format (version 1)
+=
+
+The Device Tree Source (DTS) format is a textual representation of a
+device tree in a form that can be processed by dtc into a binary
+device tree in the form expected by the kernel. The
description below
+is not a formal syntax definition of DTS, but describes the basic
+constructs used to represent device trees.
+
+Node and property definitions
+-
+
+Device tree nodes are defined with a node name and unit address with
+braces marking the start and end of the node definition. They may be
+preceded by a label.
+
+ [label:] [EMAIL PROTECTED] {
+ [properties definitions]
+ [child nodes]
+ }
+
+Nodes may contain property definitions and/or child node
+definitions. If both are present, properties must come before child
+nodes.
+
+Property definitions are name value pairs in the form:
+ [label:] property-name = value;
+except for properties with empty (zero length) value which have the
+form:
+ [label:] property-name;
+
+Property values may be defined as an array of 32-bit integer
cells, as
+NUL-terminated strings, as bytestrings or a combination of these.
+
+* Arrays of cells are represented by angle brackets surrounding a
+ space separated list of C-style integers
+
+ e.g. interrupts = 17 0xc;
+
+* A 64-bit value is represented with two 32-bit cells.
+
+ e.g. clock-frequency = 0x0001 0x;
+
+* A NUL-terminated string value is represented using double quotes
+ (the property value is considered to include the terminating NUL
+ character).
+
+ e.g. compatible = simple-bus;
+
+* A bytestring is enclosed in square brackets [] with each byte
+ represented by two hexadecimal digits. Spaces between
each byte are
+ optional.
+
+ e.g. local-mac-address = [00 00 12 34 56 78]; or equivalently
+ local-mac-address = [12345678];
+
+* Values may have several comma-separated components, which are
+ concatenated together.
+ e.g. compatible = ns16550, ns8250;
+ example = 0xf00f 19, a strange property format;
+
+* In a cell array a reference to another node will be
expanded to that
+ node's phandle. References may by '' followed by a node's label:
+ e.g. interrupt-parent = mpic ;
+ or they may be '' followed by a node's full path in braces:
+ e.g. interrupt-parent = {/soc/[EMAIL PROTECTED] ;
+
+* Outside a cell array, a reference to another node will be expanded
+ to that node's full path.
+ e.g. ethernet0 = EMAC0;
+
+* Labels may also appear before or after any component of a property
+ value, or between cells of a cell array, or between bytes of a
+ bytestring.
+ e.g. reg = reglabel: 0 sizelabel: 0x100;
+ e.g. prop = [ab cd ef byte4: 00 ff fe];
+ e.g. str = start: string value end: ;
+
+
+File layout
+---
+
+Version 1 DTS files have the overall layout:
+ /dts-v1/;
+
+ [memory reservations]
+
+ / {
+ [property definitions]
+ [child nodes]
+ };
+
+* The /dts-v1/; must be present to identify the file as a version 1
+ DTS (dts files without this tag will be treated by dtc as being in
+ the obsolete version 0, which uses a different format
for integers
+ amongst other small but incompatible changes).
+
+* Memory reservations define an entry for the device tree blob's
+ memory reservation table. They have the form:
+ e.g. /memreserve/ address length;
+ Where address and length are 64-bit C-style integers.
+
+* The / { ... }; section defines the root node of the device tree.
+
+* C style (/* ... */) and C++ style (// ...) comments are supported.
+
+
+
+ -- David Gibson [EMAIL PROTECTED]
+ -- Yoder Stuart [EMAIL PROTECTED]
--
David Gibson | I'll have my
RE: Refactor booting-without-of.txt
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Grant Likely Sent: Monday, October 15, 2007 11:09 AM To: linuxppc-dev; [EMAIL PROTECTED] Subject: Refactor booting-without-of.txt Adding the Linux expected device tree bindings to booting-without-of.txt seems to be getting a little unwieldy. Plus with more than one arch using the device tree (powerpc, sparc microblaze) the device tree bindings aren't necessarily powerpc only (the Xilinx devices certainly fall in this category). Anyone have comments about splitting the expected device tree bindings out of booting-without-of.txt into a separate directory? Perhaps something like this; each file contains common bindings for the type of device and device specific properties: Documentation/of/ Documentation/of/README - Description of the purpose and layout of this directory Documentation/of/net.txt - network device bindings (eth, MDIO, phy, etc) Documentation/of/serial.txt - serial device bindings Documentation/of/misc.txt - anything that doesn't fit anywhere else yet. Documentation/of/soc/* - System on chip stuff that doesn't fit will into established device types; possibly a separate file for each chip. Documentation/of/usb.txt - usb blah blah blah Documentation/of/whatever - you get the picture. I agree in principle with what your are proposing. One other thing to consider-- as has been publicly announced in several forums, a committee in power.org (including several folks on this thread) is working on a standard called the ePAPR which in general is attempting to standardize the base set of requirements and boot conventions that apply to the flat device tree. There will not be much device specific stuff to start with. The ePAPR document is actually quite far a long and is well beyond the 'idea' stage. The one point is that we hope that the device tree with be useful for other embedded OSes beyond Linux. So long term, I think this documentation should be pulled out of the kernel source and put on a public wiki that is not tied directly to Linux. What you are proposing is a good start... Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, October 31, 2007 12:06 PM To: Yoder Stuart-B08248 Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org Subject: Re: RFC: replace device_type with new class property? On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote: This works...but certainly is weaker with respect to standardization. My previous argument had the assumption that something like mac-address in a network node was _required_, and thus needed a class id of some sort to tie the standardized node to. It is certainly not required -- the device could have an eeprom, or it might not be ethernet at all. Fine, I picked a bad example. My point was that if a property was _required_ that it should have a class id of some sort that ties it back to the standard that required it. Stuart ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
Explicitly specifying what device class bindings / conventions the
node complies with is cute, but not actually all that useful in
practice. If it looks like a duck class device node, and it
quacks^Whas the properties of a duck class device node, it's duck
class compliant.
Don't know how cute it is, but I think it is practically
helpful. Take another example:
Say you-- a human reader-- see this in a device
tree:
...
interrupts = b 8;
interrupt-parent = mpic ;
...
What does the 'b' and '8' mean? You look
at the interrupt controller node--
mpic: [EMAIL PROTECTED] {
clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 4 4;
compatible = fsl,xyz;
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
device_type = open-pic; makes it perfectly clear.
It's an open-pic type controller and follows that
binding.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
-Original Message-
From: Wood Scott-B07421
Sent: Tuesday, October 30, 2007 11:34 AM
To: Yoder Stuart-B08248
Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type with new class property?
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
mpic: [EMAIL PROTECTED] {
clock-frequency = 0;
interrupt-controller;
#address-cells = 0;
#interrupt-cells = 2;
reg = 4 4;
compatible = fsl,xyz;
big-endian;
}
Note-- I removed the device_type property and changed
compatible somewhat. How are you going to find where
the meaning interrupt controller's interrupt cells are
defined? What spec will you look at?
The binding for fsl,xyz.
Not every string listed in compatible has a spec
backing it (or should be required to). You would
have to go look at the source code and cross your
fingers that the comments were sufficient.
Another good reason for device_type-- it helps
distinguish between two similar classes of devices.
Both open-pic and isa-pic look very similar but
have different encodings of their interrupt cells.
Without a device_type it may be difficult or impossible
to distinguish them unless the name and
compatible are luckily clear enough.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RFC: replace device_type with new class property?
We've had some discussions internally here at Freescale among various PPC Linux developers about the device_type property and how 'classes' of devices should be represented in the device tree. Taking a long term view, the question I'd like to pose is how should classes of device should be identified in the flat device tree model? A device class, as I'm using it, refers basically to general categories of devices-- devices that share common properties. Examples in current device would be cpu, memory, pci, network, serial. Today the device_type property serves this purpose to some degree. However, the original meaning of device_type in Open Firmware is related to the method interface of a node it has a recent history of abuse in the Linux kernel DTS files, with a plethora of types made up in an ad hoc way. In addition, an OS can match on compatible and in the absence of method interfaces really doesn't need device_type anyway. However, one good thing about device_type (if properly used) is that it could identify which device nodes follow an official binding, vs proprietary devices or one-off device node definitions. Without something like device_type the _human_ reader of a DTS file has to infer from the name or compatible what the device type is. So, device class identifiers like memory, cpu, serial, pci, network provide that clarity. So, what should the long term approach be? Here are a couple of options: 1. Keep device_type, with it's use specifically defined to mean that the node with that property implements an 'official' binding. In the flat device tree model a binding is just a defined set of required (and optional properties. 2. Get rid of device_type and create a _new_ property like class. The only nodes permitted to have this property are those with 'official' bindings. These nodes would have a set of required (and optional) properties. The benefit of a new property is cutting all baggage associated with the old device_type property. One other point-- the intent of a device class is not necessarily to specify a sufficient set of properties to implement drivers. The network class would have a base set of required properties (e.g. mac-address,etc), but most likely would need additional properties to implement a driver for a specific device. The value in the class is when a developer needs to represent a new device that fits into an existing class he has a base set of properties to start with that has had some good thinking put into defining it. A device class would facilitate and encourage consistent use of properties names, which would be a good thing. The initial list of official classes would be small-- cpu,memory, cache, pci, serial, network, open-pic(?). As other types get codified in actual use and have official bindings specified (perhaps through power.org) new types would be supported--e.g. i2c, jdec-flash. Thoughts? Stuart Yoder Freescale Semiconductor, Inc. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
This is bad IMHO because the human reader has to
infer the class of device. Can the human reader
tell if it implements a standardized binding or
not??
#2 use device_type
[EMAIL PROTECTED] {
device_type = network;
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
};
This is better...I can tell it implments the network
binding. The problem is the past abuse and OF
connotations.
#3 use a new class property
[EMAIL PROTECTED] {
class = network;
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
};
This is good...I can tell it implments the network
binding. There is no association with the abused
OF device_type.
#4 use compatible
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth,[official spec],network;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
};
I don't like this...we are overloading compatible with
stuff that is not specifying a programming interface. compatible
is supposed to be specifying a programming interface which
the device complies to.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: RFC: replace device_type with new class property?
-Original Message-
From: Wood Scott-B07421
Sent: Monday, October 29, 2007 2:44 PM
To: Yoder Stuart-B08248
Cc: Matt Sealey; Dale Farnsworth; Linuxppc-dev@ozlabs.org
Subject: Re: RFC: replace device_type with new class property?
Yoder Stuart-B08248 wrote:
Here's an example of what I'm trying to get at-- take
a node from a FSL device tree. The ideas I've heard
for expressing the class are like this--
#1 don't express any class at all:
[EMAIL PROTECTED] {
compatible = fsl,ucc_geth;
model = UCC;
device-id = 3;
reg = 2200 200;
interrupts = 22;
interrupt-parent = qeic ;
mac-address = [ 00 00 00 00 00 00 ];
local-mac-address = [ 00 00 00 00 00 00 ];
rx-clock = 19;
tx-clock = 1a;
phy-handle = phy3 ;
pio-handle = pio3 ;
Of course, this should properly be something like
[EMAIL PROTECTED] {
compatible = fsl,mpc8360-qe-enet, fsl,qe-enet;
local-mac-address = [ 00 00 00 00 00 00 ];
...
};
With no mac-address, and a more useful model if any at all.
That's fine, but as a human reader there is nothing
that would tell me this node implemented a defined
binding that specified required properties.
Stuart
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
