Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
On Mon, Nov 5, 2012 at 2:40 PM, Grant Likely wrote: > Jane is building custom BeagleBone expansion boards called 'capes'. She > can boot the system with a stock BeagleBoard device tree, but additional > data is needed before a cape can be used. She could replace the FDT file > used by U-Boot with one that contains the extra data, but she uses the > same Linux system image regardless of the cape, and it is inconvenient > to have to select a different device tree at boot time depending on the > cape. What's wrong with having the boot loader detect the presence of the Cape and update the device tree accordingly? We do this all the time in U-Boot. Doing stuff like reading EEPROMs and testing for the presence of hardware is easier in U-Boot than in Linux. For configurations that can be determined by the boot loader, I'm not sure overlays are practical. > Nigel is building a real-time video processing system around a MIPS SoC > and a Virtex FPGA. Video data is streamed through the FPGA for post > processing operations like motion tracking or compression. The FPGA is > configured via the SPI bus, and is also connected to GPIO lines and the > memory mapped peripheral bus. Nigel has designed several FPGA > configurations for different video processing tasks. The user will > choose which configuration to load which can even be reprogrammed at > runtime to switch tasks. Now this, on the other hand, makes more sense. If the hardware configuration is literally user-configurable, then okay. However, I'm not sure I see the need to update the device tree. The device tree is generally for hardware that cannot be discovered/probed by the device driver. If we're loading a configuration from user space, doesn't the driver already know what the hardware's capabilities are, since it's the one doing the uploading of a new FPGA code? Why not skip the device tree update and just tell the driver what the new capabilities are? -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the kvm-ppc tree with the powerpc-merge tree
On Wed, Oct 10, 2012 at 8:18 PM, Stephen Rothwell wrote: > arch/powerpc/include/asm/epapr_hcalls.h | 511 > -- > arch/powerpc/include/uapi/asm/Kbuild |1 + > arch/powerpc/include/uapi/asm/epapr_hcalls.h | 511 > ++ What is include/uapi? epapr_hcalls.h is not a user-space header file. I don't remember seeing the original patch which moved it, so I don't know where this comes from. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4 v6] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
Varun Sethi wrote: > 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 > (ti...@freescale.com). > > Signed-off-by: Timur Tabi > Signed-off-by: Varun Sethi > --- Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4 v5] iommu/fsl: Add iommu domain attributes required by fsl PAMU driver.
Joerg Roedel wrote: > When you add implementation specific attributes please add some > indication to the names that it is only for PAMU. DOMAIN_ATTR_STASH > sounds too generic. We were thinking that maybe this attribute could be useful to other IOMMUs in the future. Stashing is not a concept that would only work on Freescale processors. But we'll change it if you insist. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4 v6] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
Sethi Varun-B16395 wrote: > This would in any case change with the new LIODN allocation scheme. I > intend on introducing the new scheme as a separate patch. At the very least, you should detect when an LIODN is too large and print an error message. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
On Wed, Oct 17, 2012 at 12:32 PM, Varun Sethi wrote:
> + * Copyright (C) 2012 Freescale Semiconductor, Inc.
Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "fsl_pamu.h"
> +
> +/* PAMU bypass enbale register contains control bits for
> + * enabling bypass mode on each PAMU.
> + */
/*
* Linux multi-line comments
* look like this.
*/
> +#define PAMUBYPENR 0x604
Update struct ccsr_guts instead.
http://patchwork.ozlabs.org/patch/141649/
> +
> +/* define indexes for each operation mapping scenario */
> +#define OMI_QMAN0x00
> +#define OMI_FMAN0x01
> +#define OMI_QMAN_PRIV 0x02
> +#define OMI_CAAM0x03
> +
> +static paace_t *ppaact;
> +static paace_t *spaact;
> +static struct ome *omt;
> +unsigned int max_subwindow_count;
> +
> +struct gen_pool *spaace_pool;
> +
> +static paace_t *pamu_get_ppaace(int liodn)
> +{
> + if (!ppaact) {
> + pr_err("PPAACT doesn't exist\n");
pr_err("fsl-pamu: PPAACT has not been initialized\n");
Make sure ALL pr_xxx() messages in this file start with "fsl-pamu: "
> + return NULL;
> + }
> +
> + return &ppaact[liodn];
Bounds checking?
> +}
> +
> +/** Sets validation bit of PACCE
> + *
> + * @parm[in] liodn PAACT index for desired PAACE
> + *
> + * @return Returns 0 upon success else error code < 0 returned
> + */
> +int pamu_enable_liodn(int liodn)
> +{
> + paace_t *ppaace;
> +
> + ppaace = pamu_get_ppaace(liodn);
> + if (!ppaace)
> + return -ENOENT;
error message?
> +
> + if (!get_bf(ppaace->addr_bitfields, PPAACE_AF_WSE)) {
> + pr_err("liodn %d not configured\n", liodn);
> + return -EINVAL;
> + }
> +
> + /* Ensure that all other stores to the ppaace complete first */
> + mb();
> +
> + ppaace->addr_bitfields |= PAACE_V_VALID;
> + mb();
> +
> + return 0;
> +}
> +
> +/** Clears validation bit of PACCE
> + *
> + * @parm[in] liodn PAACT index for desired PAACE
> + *
> + * @return Returns 0 upon success else error code < 0 returned
This is not proper kerneldoc format.
> + */
> +int pamu_disable_liodn(int liodn)
> +{
> + paace_t *ppaace;
> +
> + ppaace = pamu_get_ppaace(liodn);
> + if (!ppaace)
> + return -ENOENT;
error message?
> +
> + set_bf(ppaace->addr_bitfields, PAACE_AF_V, PAACE_V_INVALID);
> + mb();
> +
> + return 0;
> +}
> +
> +
> +static unsigned int map_addrspace_size_to_wse(phys_addr_t addrspace_size)
> +{
> + BUG_ON((addrspace_size & (addrspace_size - 1)));
> +
> + /* window size is 2^(WSE+1) bytes */
> + return __ffs(addrspace_size >> PAMU_PAGE_SHIFT) + PAMU_PAGE_SHIFT - 1;
> +}
> +
> +static unsigned int map_subwindow_cnt_to_wce(u32 subwindow_cnt)
> +{
> + /* window count is 2^(WCE+1) bytes */
> + return __ffs(subwindow_cnt) - 1;
> +}
> +
> +static void pamu_setup_default_xfer_to_host_ppaace(paace_t *ppaace)
> +{
> + set_bf(ppaace->addr_bitfields, PAACE_AF_PT, PAACE_PT_PRIMARY);
> +
> + set_bf(ppaace->domain_attr.to_host.coherency_required,
> PAACE_DA_HOST_CR,
> + PAACE_M_COHERENCE_REQ);
> +}
> +
> +static void pamu_setup_default_xfer_to_host_spaace(paace_t *spaace)
> +{
> + set_bf(spaace->addr_bitfields, PAACE_AF_PT, PAACE_PT_SECONDARY);
> + set_bf(spaace->domain_attr.to_host.coherency_required,
> PAACE_DA_HOST_CR,
> + PAACE_M_COHERENCE_REQ);
> +}
> +
> +static paace_t *pamu_get_spaace(u32 fspi_index, u32 wnum)
> +{
> + return &spaact[fspi_index + wnum];
bounds checking?
> +}
> +
> +static unsigned long pamu_get_fspi_and_allocate(u32 subwin_cnt)
> +{
subwin_cnt should probably be an unsigned int.
This function needs to be documented. What value is being returned?
> + unsigned long spaace_addr;
> +
> + spaace_addr = gen_pool_alloc(spaace_pool, subwin_cnt *
> sizeof(paace_t));
> + if (!spaace_addr)
> + return ULONG_MAX;
What's wrong with returning 0 on error?
> +
> + return (spaace_addr - (unsigned long)spaact) / (sizeof(paace_t));
Is this supposed to be a virtual address? If so, then return void*
instead of an unsigned long.
> +}
> +
> +void pamu_free_subwins(int liodn)
> +{
> + paace_t *ppaace;
> + u32 subwin_cnt, size;
subwin_cnt should probably be an unsigned int.
> +
> + ppaace = pamu_get_ppaace(liodn);
> + if (!ppaace)
> + return;
error message
> +
> + if (get_bf(ppaace->addr_bitfields, PPAACE_AF_MW)) {
> + subwin_cnt = 1UL << (get_bf(ppaace->impl_attr, PAACE_IA_WCE)
> + 1);
> + size = (subwin_cnt - 1) * sizeof(paace_t);
> + gen_pool_free(spaace_pool, (unsigned
> long)&spaact[ppaace->fspi], size);
> +
Re: [PATCH 1/3] powerpc/book3e: load critical/machine/debug exception stack
On Thu, Oct 25, 2012 at 1:43 AM, Tiejun Chen wrote: > We always alloc critical/machine/debug check exceptions. This is > different from the normal exception. So we should load these exception > stack properly like we did for booke. Tiejun, I'm a little confused by these patches, because the actual critical exception handlers are still commented out: /* Critical Input Interrupt */ START_EXCEPTION(critical_input); CRIT_EXCEPTION_PROLOG(0x100, BOOKE_INTERRUPT_CRITICAL, PROLOG_ADDITION_NONE) // EXCEPTION_COMMON(0x100, PACA_EXCRIT, INTS_DISABLE) // bl special_reg_save_crit // CHECK_NAPPING(); // addir3,r1,STACK_FRAME_OVERHEAD // bl .critical_exception // b ret_from_crit_except b . Are you working on fixing this? I'm trying to fix it, too, but I think you're way ahead of me. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] powerpc: Bail out of KGDB when we've been triggered
On Wed, Aug 22, 2012 at 5:43 AM, Tiejun Chen wrote:
> +int kgdb_skipexception(int exception, struct pt_regs *regs)
> +{
> + if (kgdb_isremovedbreak(regs->nip))
> + return 1;
> +
> + return 0;
> +}
int kgdb_skipexception(int exception, struct pt_regs *regs)
{
return !!kgdb_isremovedbreak(regs->nip));
}
If the caller only cares about zero vs. non-zero, you can drop the !!.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] fsl_pmc: Add API to enable device as wakeup event source
On Tue, Aug 7, 2012 at 3:43 AM, Zhao Chenhui wrote:
> +int mpc85xx_pmc_set_wake(struct device *dev, bool enable)
> +{
> + int ret = 0;
> + struct device_node *clk_np;
> + const u32 *prop;
> + u32 pmcdr_mask;
> +
> + if (!pmc_regs) {
> + pr_err("%s: PMC is unavailable\n", __func__);
You have a 'struct device', so please use dev_err instead.
> + return -ENODEV;
> + }
> +
> + if (enable && !device_may_wakeup(dev))
> + return -EINVAL;
> +
> + clk_np = of_parse_phandle(dev->of_node, "fsl,pmc-handle", 0);
> + if (!clk_np)
> + return -EINVAL;
> +
> + prop = of_get_property(clk_np, "fsl,pmcdr-mask", NULL);
> + if (!prop) {
> + ret = -EINVAL;
> + goto out;
> + }
> + pmcdr_mask = be32_to_cpup(prop);
> +
> + if (enable)
> + /* clear to enable clock in low power mode */
> + clrbits32(&pmc_regs->pmcdr, pmcdr_mask);
> + else
> + setbits32(&pmc_regs->pmcdr, pmcdr_mask);
> +
> +out:
> + of_node_put(clk_np);
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(mpc85xx_pmc_set_wake);
Use EXPORT_SYMBOL, not EXPORT_SYMBOL_GPL.
> +
> +/**
> + * mpc85xx_pmc_set_lossless_ethernet - enable lossless ethernet
> + * in (deep) sleep mode
> + * @enable: True to enable event generation; false to disable
> + */
> +void mpc85xx_pmc_set_lossless_ethernet(int enable)
Should this be 'bool enable'?
> @@ -21,6 +22,17 @@ struct device_node;
>
> extern void fsl_rstcr_restart(char *cmd);
>
> +#ifdef CONFIG_FSL_PMC
> +extern int mpc85xx_pmc_set_wake(struct device *dev, bool enable);
> +extern void mpc85xx_pmc_set_lossless_ethernet(int enable);
Don't use 'extern' for functions.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] fsl_pmc: Add API to enable device as wakeup event source
Zhao Chenhui wrote: >>> > >+#ifdef CONFIG_FSL_PMC >>> > >+extern int mpc85xx_pmc_set_wake(struct device *dev, bool enable); >>> > >+extern void mpc85xx_pmc_set_lossless_ethernet(int enable); >> > >> >Don't use 'extern' for functions. >> > > Why? I think there is no difference. It's unnecessary, and it makes the line longer. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the kvm-ppc tree with the powerpc-merge tree
On Wed, Oct 10, 2012 at 9:47 PM, Stephen Rothwell wrote:
> Commit 549d62d889b4 ("KVM: PPC: use definitions in epapr header
> for hcalls") from the kvm-ppc tree added an include of asm/epapr_hcall.h
> to the user visible part of asm/kvm_para.h so asm/epapr_hcall.h became a
> user visible header file.
Any real user-space code that tries to call any of the functions in
epapr_hcall.h will cause an exception.
Claiming that kernel header files that KVM needs are suddenly
user-space header files doesn't make much sense to me, but I guess
it's not my decision.
--
Timur Tabi
Linux kernel developer at Freescale
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH 0/2] dmaengine: Fix compillation issues in device_prep_dma_cyclic()
On Mon, Sep 24, 2012 at 2:58 AM, Peter Ujfalusi wrote: > PS: I did build tested the series on ARM (OMAP), x86_32, x86_64 but not for > ppc > for sure. For the record, patch #1 fixes the build break on PowerPC. Thanks. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [for 3.4] drivers/virt: the Freescale hypervisor driver doesn't need to check MSR[GS]
On Thu, May 17, 2012 at 2:10 PM, Timur Tabi wrote: > The MSR[GS] bit indicates whether the kernel is running in processor guest > state mode, but such a check is unnecessary. The driver already checks > for the /hypervisor node and the fsl,hv-version property, so it already > knows that it's running under the Freescale hypervisor. > > There is nothing in the driver that inherently requires guest state, > anyway. > > This fixes a break that can occur in some randconfig builds. > > Signed-off-by: Timur Tabi > --- Kumar, I posted this patch back in May. Can you apply it, please? It fixes a build break. -- Timur Tabi Linux kernel developer at Freescale -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
