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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] powerpc/fsl: add timer wakeup source
On Wed, Oct 3, 2012 at 5:42 AM, Wang Dongsheng wrote: > > > Signed-off-by: Wang Dongsheng Wang, Your patches must always have a From: line of your Freescale email address. Do not use your gmail.com address to send patches. This needs to be fixed when this patch is applied. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpic: add global timer support
On Wed, Oct 3, 2012 at 5:38 AM, Wang Dongsheng wrote: > diff --git a/arch/powerpc/include/asm/mpic_timer.h > b/arch/powerpc/include/asm/mpic_timer.h > new file mode 100644 > index 000..2428972 > --- /dev/null > +++ b/arch/powerpc/include/asm/mpic_timer.h > @@ -0,0 +1,39 @@ > +/* > + * arch/powerpc/include/asm/mpic_timer.h > + * > + * Mpic Global Timer Header > + * > + * Copyright 2012 Freescale Semicondutor, Inc. When this patch is applied, please fix the misspelling of "Semiconductor". -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix typos in Freescale copyright claims
On Thu, Nov 1, 2012 at 11:53 PM, Li Yang wrote: > There are many cases that Semiconductor is misspelled. The patch > fix these typos. > > Signed-off-by: Li Yang Acked-by: Timur Tabi I can't believe I've been staring at these files for all these years and never noticed the misspelligs. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 15/25] powerpc/fsl_msi: add a const qualifier
On Mon, Jul 23, 2012 at 4:13 AM, Uwe Kleine-König wrote: > This prepares *of_device_id.data becoming const. Without this change > the following warning would occur: > > arch/powerpc/sysdev/fsl_msi.c: In function 'fsl_of_msi_probe': > arch/powerpc/sysdev/fsl_msi.c:379:11: error: assignment discards > 'const' qualifier from pointer target type [-Werror] > > Signed-off-by: Uwe Kleine-König Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/2] mmc: Move mmc_delay() to include/linux/mmc/core.h
On Mon, Sep 24, 2012 at 8:17 AM, Arnd Bergmann wrote:
>
>> static inline void mmc_delay(unsigned int ms)
>> {
>> msleep(ms);
>> }
>
> That would be my preferred choice, unless someone has specific issues with
> this.
If we're going to do that, then just get rid of mmc_delay and replace
all calls to it with msleep(). Why bother with the inline function?
There's nothing really MMC-specific about it.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC64 & DMA zone
On Fri, Aug 17, 2012 at 3:40 PM, Benjamin Herrenschmidt wrote: > On Fri, 2012-08-17 at 23:04 +0300, Aaro Koskinen wrote: >> Hi, >> >> Is there a way to reduce/limit DMA zone with PPC64 kernel (3.6-rcX) >> on G5 Mac? I have tried to search Kconfig or command line options, >> but can't find anything. > > No. What about Shaohui patches for ZONE_DMA? That's meant to solve exactly this problem? Granted, it sets the DMA zone to 31 bits, but it's simple to hack that to 30 bits. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] QE USB host fix for mpc832x
On Wed, Aug 22, 2012 at 10:54 PM, Ben Dubb wrote: > This patch should be used to get QE USB host mode working on mpc832x and > mpc8360 > based devices. It fixes the following issues: > > - BRG divisor shall not be an add number greater than 3. > - USB param block in multi-user ram can't be accessed at default location on > mpc832x > device. Allocate it dynamically. I think this should be two separate patches. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] i2c-mpc: Wait for STOP to hit the bus
On Thu, Aug 30, 2012 at 5:40 AM, Joakim Tjernlund
wrote:
> - mpc_i2c_stop(i2c);
> + mpc_i2c_stop(i2c); /* Initiate STOP */
> + orig_jiffies = jiffies;
> + /* Wait until STOP is seen, allow up to 1 s */
> + while (readb(i2c->base + MPC_I2C_SR) & CSR_MBB) {
> + if (time_after(jiffies, orig_jiffies + HZ)) {
> + u8 status = readb(i2c->base + MPC_I2C_SR);
> +
> + dev_dbg(i2c->dev, "timeout\n");
> + if ((status & (CSR_MCF | CSR_MBB | CSR_RXAK)) != 0) {
> + writeb(status & ~CSR_MAL,
> + i2c->base + MPC_I2C_SR);
> + mpc_i2c_fixup(i2c);
> + }
> + return -EIO;
> + }
> + cond_resched();
> + }
Shouldn't the while-loop be inside mpc_i2c_stop() itself?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/usb: fix bug of CPU hang when missing USB PHY clock
On Fri, Aug 10, 2012 at 5:48 AM, Shengzhou Liu
wrote:
> + for (timeout = 1000; timeout > 0; timeout--) {
> + /* check PHY_CLK_VALID to get phy clk valid */
> + if (in_be32(non_ehci + FSL_SOC_USB_CTRL)
> + & PHY_CLK_VALID)
> + break;
> + udelay(1);
> + }
Use spin_event_timeout() instead.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V6 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
On Aug 14, 2012, at 10:56 PM, "Jia Hongtao-B38951" wrote: >> >>> >>> +EXPORT_SYMBOL_GPL(mpc85xx_pci_err_probe); >> >> Make this EXPORT_SYMBOL. >> > > Hi Timur and Kumar: > > I'm a little confused. > Should we remove _GPL for upstream version too? Yes. > > -Hongtao. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V6 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
On Fri, Aug 10, 2012 at 3:19 AM, Jia Hongtao wrote: > > +EXPORT_SYMBOL_GPL(mpc85xx_pci_err_probe); Make this EXPORT_SYMBOL. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/mpic: add global timer support
On Fri, Aug 10, 2012 at 12:54 AM, wrote: > From: Wang Dongsheng > +EXPORT_SYMBOL_GPL(mpic_request_timer); Make these EXPORT_SYMBOL. No need for a GPL restriction. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/epapr: export epapr_hypercall_start
On Sat, Aug 11, 2012 at 2:01 AM, Geert Uytterhoeven wrote: > On Sat, Aug 11, 2012 at 12:21 AM, Scott Wood wrote: >> +EXPORT_SYMBOL(epapr_hypercall_start); > > EXPORT_SYMBOL_GPL? We prefer EXPORT_SYMBOL. We don't want to restrict our customers from having to use GPL code. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/e500v2: Add power isa properties to comply with ePAPR 1.1
On Wed, Aug 8, 2012 at 1:53 AM, Olivia Yin wrote:
> The patch update all e500v2 platforms.
Could you provide some more information about the ePAPR requirement?
> + * e500v2 power isa Device Tree Source (include)
Power ISA
> + *
> + * Copyright 2012 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
Please use normal quotation marks
"AS IS"
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2 PATCH 1/1] booke/wdt: some ioctls do not return values properly
On Mon, Aug 6, 2012 at 8:59 PM, Tiejun Chen wrote: > Fix some booke wdt ioctls return value error. > > Signed-off-by: Tiejun Chen It's not the greatest patch description, but it'll do. Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] booke/wdt: fix incorrect WDIOC_GETSUPPORT return path
On Mon, Aug 6, 2012 at 2:12 PM, Tabi Timur-B04825 wrote: > On Mon, Jul 30, 2012 at 3:15 AM, Tiejun Chen > wrote: >> We miss that correct WDIOC_GETSUPPORT return path when perform >> copy_to_user() properly. > > Thanks for catching this. I'm amazed that this driver still has bugs like > this. While you're at it, I found a few related bugs. Can you fix these, also? 1. case WDIOC_SETOPTIONS: if (get_user(tmp, p)) return -EINVAL; This should return -EFAULT. 2. case WDIOC_GETBOOTSTATUS: /* XXX: something is clearing TSR */ tmp = mfspr(SPRN_TSR) & TSR_WRS(3); /* returns CARDRESET if last reset was caused by the WDT */ return (tmp ? WDIOF_CARDRESET : 0); This should use put_user() to return the value, instead of returning it as a return code. You can title the new patch something like, "booke/wdt: some ioctls do not return values properly" -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] booke/wdt: fix incorrect WDIOC_GETSUPPORT return path
On Mon, Jul 30, 2012 at 3:15 AM, Tiejun Chen wrote:
> We miss that correct WDIOC_GETSUPPORT return path when perform
> copy_to_user() properly.
Thanks for catching this. I'm amazed that this driver still has bugs like this.
> diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
> index 3fe82d0..2be7f29 100644
> --- a/drivers/watchdog/booke_wdt.c
> +++ b/drivers/watchdog/booke_wdt.c
> @@ -162,12 +162,13 @@ static long booke_wdt_ioctl(struct file *file,
> unsigned int cmd, unsigned long arg)
> {
> u32 tmp = 0;
> - u32 __user *p = (u32 __user *)arg;
> + void __user *argp = (u32 __user *)arg;
> + u32 __user *p = argp;
You don't need to create 'argp'. The existing 'p' variable will work
in the copy_to_user() call.
> + return copy_to_user(argp, &ident,
> + sizeof(ident)) ? -EFAULT : 0;
This can fit in one line, especially if you use 'p' instead of 'argp'.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V4 3/3] powerpc/fsl-pci: Unify pci/pcie initialization code
On Fri, Aug 3, 2012 at 11:09 AM, Scott Wood wrote: > p1022ds OTOH is weird enough that it deserves its own board file. What's so weird about the P1022DS? Also, why do we need a default PCI bus if one isn't specified in the device tree? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc/85xx: add Freescale P5040 SOC and SEC v5.2 device trees
On Jul 25, 2012, at 5:38 PM, "Phillips Kim-R1AAHA" wrote: > On Wed, 25 Jul 2012 16:59:49 -0500 > Timur Tabi wrote: > >> Add device tree (dtsi) files for the Freescale P5040 SOC. Since this >> SOC introduces SEC v5.2, add the dtsi file for that also. >> >> Signed-off-by: Timur Tabi >> --- > > mind retaining the original authors' signoffs? Doh! Sorry about that. > > Kim ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/3][PATCH][upstream] TDM Framework
Michael Ellerman wrote: > I agree these values are odd. But there's no rule that you can only use > an enum if the values are monotonically increasing. > > It can still serve as helpful documentation, and reduce the number of > places you pass a bare int around. IMHO, an enum should only be used if 1) You are doing real type checking of the enum 2) You don't care what the actual values of each enum is For this patch, neither is true. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
Benjamin Herrenschmidt wrote: > Sure but I don't want to create the zones in the first place (and thus > introduce the added pressure on the memory management) on machines that > don't need it. One thing that does confuse me -- by default, we don't create a ZONE_NORMAL. We only create a ZONE_DMA. Why is that? Shouldn't it be the other way around? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
Benjamin Herrenschmidt wrote: > Sure but I don't want to create the zones in the first place (and thus > introduce the added pressure on the memory management) on machines that > don't need it. Ah yes, I forgot about memory pressure. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: add ZONE_NORMAL zone for 64 bit kernel
On Mon, Jul 23, 2012 at 5:20 PM, Benjamin Herrenschmidt wrote: > And ? Who cares ? Drivers who know about a 32-bit limitations use > GFP_DMA32, that's what is expected, don't mess around with ZONE_DMA. I thought drivers are supposed to set a dma_mask, and dma_alloc_coherent() is supposed to use that to figure out how to honor that mask. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [2/3][PATCH][upstream] TDM Framework
On Mon, Jul 23, 2012 at 5:49 AM, wrote:
> From: Sandeep Singh
Please fix your git configuration so that the From: line in your
emails contains your full name. This patch was sent with this From:
line:
From:
It should say:
From: Sandeep Singh
Three more things:
1) You don't need to add [upstream] to patches that are posted upstream.
2) This patch needs to be CC'd to linux-ker...@vger.kernel.org and
de...@driverdev.osuosl.org.
3) I'm concerned that there is no "struct device" anywhere in this
framework. I think that's a serious omission, and you need to figure
out where you can put this.
> diff --git a/drivers/tdm/tdm-core.c b/drivers/tdm/tdm-core.c
> new file mode 100644
> index 000..9973b6b
> --- /dev/null
> +++ b/drivers/tdm/tdm-core.c
> @@ -0,0 +1,1082 @@
> +/* driver/tdm/tdm-core.c
> + *
> + * Copyright (C) 2012 Freescale Semiconductor, Inc, All rights reserved.
I've been seeing this copyright messages a lot recently, and I don't
understand why. This message is incorrectly formatted. The "(C)" is
redundant, and the phrase "All rights reserved." is wrong. This patch
is licensed under the GPL, so we are NOT reserving all rights, we are
actually giving up some rights.
Please change this to:
Copyright 2012 Freescale Semiconductor, Inc.
> + *
> + * TDM core is the interface between TDM clients and TDM devices.
> + * It is also intended to serve as an interface for line controlled
> + * devices later on.
> + *
> + * Author:Hemant Agrawal
> + * Rajesh Gumasta
If these two are the authors, why are they not on the signed-off-by lines?
> + *
> + * Modified by Sandeep Kr Singh
> + * Poonam Aggarwal
Do not add "modified" by lines to the code. That's why we have a git history.
> + * 1. Added framework based initialization of device.
> + * 2. All the init/run time configuration is now done by framework.
> + * 3. Added channel level operations.
> + * 4. Added sysfs knob to configure use_latest_tdm_data at runtime.
Again, this is not information that belongs in the source file.
> + *
> + * Note that some parts of this code may have been derived from i2c
> subsystem.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with this program; if not, write to the Free Software Foundation, Inc.,
> + * 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Are you sure you need all of these header files?
> +
> +
> +static DEFINE_MUTEX(tdm_core_lock);
> +static DEFINE_IDR(tdm_adapter_idr);
> +/* List of TDM adapters registered with TDM framework */
> +LIST_HEAD(adapter_list);
> +
> +/* List of TDM clients registered with TDM framework */
> +LIST_HEAD(driver_list);
> +
> +/* In case the previous data is not fetched by the client driver, the
> + * de-interleaving function will discard the old data and rewrite the
> + * new data */
Proper multi-line comment format is like this:
/*
* In case the previous data is not fetched by the client driver, the
* de-interleaving function will discard the old data and rewrite the
* new data.
*/
> +static int use_latest_tdm_data = 1;
> +
> +/* Data structures required for sysfs */
> +static struct tdm_sysfs attr = {
> + .attr.name = "use_latest_data",
> + .attr.mode = 0664,
> + .cmd_type = TDM_LATEST_DATA,
> +};
> +
> +static struct attribute *tdm_attr[] = {
> + &attr.attr,
> + NULL
> +};
> +
> +const struct sysfs_ops tdm_ops = {
> + .show = tdm_show_sysfs,
> + .store = tdm_store_sysfs,
> +};
> +
> +static struct kobj_type tdm_type = {
> + .sysfs_ops = &tdm_ops,
> + .default_attrs = tdm_attr,
> +};
Why are some of these 'const' and some aren't? They should all be 'const'
> +
> +/* tries to match client driver with the adapter */
> +static int tdm_device_match(struct tdm_driver *driver, struct tdm_adapter
> *adap)
> +{
> + /* match on an id table if there is one */
> + if (driver->id_table && driver->id_table->name[0]) {
> + if (!(strcmp(driver->id_table->name, adap->name)))
> + return (int)driver->id_table;
> + }
> + return TDM_E_OK;
Get rid of TDM_E_OK. It's the only error code that you've defined,
and it's set to 0. That doesn't mean anything.
> +}
> +
> +st
Re: [PATCH] of: require a match on all fields of of_device_id
On Tue, Jul 17, 2012 at 8:11 PM, Scott Wood wrote:
> Commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6 ("of: match by compatible
> property first") breaks the gianfar ethernet driver found on various
> Freescale PPC chips.
>
> There are, for unfortunate historical reasons, two nodes with a
> compatible of "gianfar".
Would it be worth updating the binding for the two nodes to make the
compatible property different? We could do something like this:
ethernet@24000 {
reg = <0x24000 0x1000>;
compatible = "fsl,gianfar-eth", "gianfar";
...
};
(and something similar for MDIO nodes)
and update all the drivers to look for both strings. After a few
years, we can delete "gianfar".
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc44x/watchdog: Select WATCHDOG_NOWAYOUT option
On Sun, Jul 15, 2012 at 9:07 PM, Lu.Jiang wrote: > > Since the ppc44x's watch dog can not reset by software, such operation only > set the timeout value(WDTP) to minimum, and cause the system reboot > immediately. It's supposed to set it to the maximum. That's what WDTP_MASK is supposed to do. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] ppc44x/watchdog: Select WATCHDOG_NOWAYOUT option
On Fri, Jul 13, 2012 at 7:25 AM, Josh Boyer wrote: > Right now, if the option is not set we call booke_wdt_disable which > indeed does not actually _disable_ the WDT, but it does set the timer > period to the maxium value. We could go one step further and implement > a simple timer that pops and calls booke_wdt_ping if WATCHDOG_NOWAYOUT > is not set, then rearms itself. That would leave the user with the > ability to perform recovery of the userspace process that exited or > died and was responsible for pinging the watchdog. I think the maximum value is still decades or centuries, so there's no real reason to complicate the code. The NOWAYOUT feature is working as designed, so I don't understand the need for this patch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [linuxppc-release] [PATCH v3 4/4] fsl-dma: use spin_lock_bh to instead of spin_lock_irqsave
Qiang Liu wrote: > Use spin_lock_bh to instead of spin_lock_irqsave for improving performance. You forgot to include the evidence that performance has improved, as well as an explanation why it's okay to use spin_lock_bh, and why it's faster. I told you to respin the patch with that information in the patch description. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
Kumar Gala wrote: >> > >> >./p2020rdb_camp_core1.dts >> >./p1020rdb-pc_camp_core1.dts >> >./mpc8572ds_camp_core1.dts >> >./p2020rdb_camp_core0.dts >> >./p1020rdb-pc_camp_core0.dts >> >./mpc8572ds_camp_core0.dts >> >./p1020rdb_camp_core1.dts >> >./p1020rdb_camp_core0.dts >> > > I'd be ok if we want to drop the p1020rdb as that board has been replaced > w/the p1020rdb-pc. How about dropping the P2020RDB as well? Then we have only two examples: MPC8572DS and P1020RDB-PC. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/85xx: Create dts of each core in CAMP mode for P1021RDB-PC
On Tue, Jul 10, 2012 at 3:39 AM, Xu Jiucheng wrote: > Create the dts files for each core and splits the devices between > the two cores for P1021RDB-PC. > > Core0 has l2, serial0, i2c, spi, gpio, tdm,dma, usb, eth0, eth1, > sdhc, crypto, global-util, message, pci0, pci1, msi, crypto. > Core1 has l2, serial1, eth2. > > Signed-off-by: Xu Jiucheng > Signed-off-by: Matthew McClintock > --- Do we really want AMP device trees upstream? They're very application-specific, and AMP support has always been a hack. If anything, I think we should be deleting AMP device trees from upstream, not adding more. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.4.0-rc1: No init found
On Wed, Apr 4, 2012 at 7:36 AM, Suzuki K. Poulose wrote: >> Not sure if this is related, but at the end of each kernel compilation, >> the following messages are printed: >> >> >>SYSMAP System.map >>SYSMAP .tmp_System.map >>WRAParch/powerpc/boot/zImage.pmac >> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the >> wrapper(0x40) >> INFO: Fixing the link_address of wrapper to (0x70) >>WRAParch/powerpc/boot/zImage.coff >> INFO: Uncompressed kernel (size 0x6e52f8) overlaps the address of the >> wrapper(0x50) >> INFO: Fixing the link_address of wrapper to (0x70) >>WRAParch/powerpc/boot/zImage.miboot >> INFO: Uncompressed kernel (size 0x6d4b80) overlaps the address of the >> wrapper(0x40) >> INFO: Fixing the link_address of wrapper to (0x70) >>Building modules, stage 2. >>MODPOST 24 modules >> >> >> I started to see these messages in January (around Linux 3.2.0), but never >> investigated what it was since the produced kernels continued to boot just >> fine. > > > The above change was added by me. The message is printed when the 'wrapper' > script finds that decompressed kernel overlaps the 'bootstrap code' which > does the decompression. So it shifts the 'address' of the bootstrap code to > the next higher MB. As such it is harmless. I see this message every time when I build the kernel. I know it's harmless, but is this something that can be "fixed"? That is, can we change some linker script (or whatever) to make 0x70 the default value? Or maybe modify the wrapper script to just automatically find the right spot without printing a message? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
On Tue, Jul 3, 2012 at 5:21 AM, Zhao Chenhui wrote: > Do hardware timebase sync. Firstly, stop all timebases, and transfer > the timebase value of the boot core to the other core. Finally, > start all timebases. > > Only apply to dual-core chips, such as MPC8572, P2020, etc. > > Signed-off-by: Zhao Chenhui > Signed-off-by: Li Yang Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
Zhao Chenhui wrote: > On Tue, Jul 03, 2012 at 10:17:12PM -0500, Tabi Timur-B04825 wrote: >> Zhao Chenhui wrote: >>> If the guts variable is NULL, it indicates there is error in dts or kernel. >>> We should fix the error, rather than ignore it. >> >> And that's why there's a warning message. Crashing the kernel is not >> going to fix anything. >> > > This error likely crashes the kenel somewhere. Can you test this, please? The point I'm trying to make is that it's wrong to intentionally halt the kernel unless you're sure that it's the best option. A missing device tree node is supposed to only disable a given feature, not break everything. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
Zhao Chenhui wrote: > If the guts variable is NULL, it indicates there is error in dts or kernel. > We should fix the error, rather than ignore it. And that's why there's a warning message. Crashing the kernel is not going to fix anything. > Moreover, if smp_85xx_ops.give/take_timebase is NULL, kernel can not do the > timebase sync. Is that necessary for the kernel to boot? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v7 1/5] powerpc/85xx: implement hardware timebase sync
On Tue, Jul 3, 2012 at 5:21 AM, Zhao Chenhui wrote:
> + np = of_find_matching_node(NULL, mpc85xx_smp_guts_ids);
> + if (np) {
> + guts = of_iomap(np, 0);
> + of_node_put(np);
> + if (!guts) {
> + pr_err("%s: Could not map guts node address\n",
> + __func__);
> + return;
> + }
> + smp_85xx_ops.give_timebase = mpc85xx_give_timebase;
> + smp_85xx_ops.take_timebase = mpc85xx_take_timebase;
> + }
I had this in mind:
guts = of_iomap(np, 0);
of_node_put(np);
if (guts) {
smp_85xx_ops.give_timebase = mpc85xx_give_timebase;
smp_85xx_ops.take_timebase = mpc85xx_take_timebase;
} else {
pr_err("%s: Could not map guts node address\n",
__func__);
}
That way, a missing GUTS node does not break everything.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 1/5] powerpc/85xx: implement hardware timebase sync
On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
wrote:
> Do hardware timebase sync. Firstly, stop all timebases, and transfer
> the timebase value of the boot core to the other core. Finally,
> start all timebases.
>
> Only apply to dual-core chips, such as MPC8572, P2020, etc.
>
> Signed-off-by: Zhao Chenhui
> Signed-off-by: Li Yang
> ---
> Changes for v6:
> * added 85xx_TB_SYNC
> * added isync() after set_tb()
> * removed extra entries from mpc85xx_smp_guts_ids
>
> arch/powerpc/include/asm/fsl_guts.h | 2 +
> arch/powerpc/platforms/85xx/Kconfig | 5 ++
> arch/powerpc/platforms/85xx/smp.c | 84
> +++
> 3 files changed, 91 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/fsl_guts.h
> b/arch/powerpc/include/asm/fsl_guts.h
> index aa4c488..dd5ba2c 100644
> --- a/arch/powerpc/include/asm/fsl_guts.h
> +++ b/arch/powerpc/include/asm/fsl_guts.h
> @@ -48,6 +48,8 @@ struct ccsr_guts {
> __be32 dmuxcr; /* 0x.0068 - DMA Mux Control Register
> */
> u8 res06c[0x70 - 0x6c];
> __be32 devdisr; /* 0x.0070 - Device Disable Control */
> +#define CCSR_GUTS_DEVDISR_TB1 0x1000
> +#define CCSR_GUTS_DEVDISR_TB0 0x4000
> __be32 devdisr2; /* 0x.0074 - Device Disable Control 2 */
> u8 res078[0x7c - 0x78];
> __be32 pmjcr; /* 0x.007c - 4 Power Management Jog Control
> Register */
> diff --git a/arch/powerpc/platforms/85xx/Kconfig
> b/arch/powerpc/platforms/85xx/Kconfig
> index f000d81..8dd7147 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -8,6 +8,7 @@ menuconfig FSL_SOC_BOOKE
> select FSL_PCI if PCI
> select SERIAL_8250_EXTENDED if SERIAL_8250
> select SERIAL_8250_SHARE_IRQ if SERIAL_8250
> + select 85xx_TB_SYNC if KEXEC
> default y
>
> if FSL_SOC_BOOKE
> @@ -267,3 +268,7 @@ endif # FSL_SOC_BOOKE
>
> config TQM85xx
> bool
> +
> +config 85xx_TB_SYNC
> + bool
> + default n
> diff --git a/arch/powerpc/platforms/85xx/smp.c
> b/arch/powerpc/platforms/85xx/smp.c
> index ff42490..edb0cad 100644
> --- a/arch/powerpc/platforms/85xx/smp.c
> +++ b/arch/powerpc/platforms/85xx/smp.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -42,6 +43,69 @@ extern void __early_start(void);
> #define NUM_BOOT_ENTRY 8
> #define SIZE_BOOT_ENTRY (NUM_BOOT_ENTRY * sizeof(u32))
>
> +#ifdef CONFIG_85xx_TB_SYNC
> +static struct ccsr_guts __iomem *guts;
> +static u64 timebase;
> +static int tb_req;
> +static int tb_valid;
> +
> +static void mpc85xx_timebase_freeze(int freeze)
> +{
> + unsigned int mask;
'mask' should be uint32_t
> +
> + if (!guts)
> + return;
This function should never be called if guts is NULL, so this check
should be unnecessary.
> +
> + mask = CCSR_GUTS_DEVDISR_TB0 | CCSR_GUTS_DEVDISR_TB1;
> + if (freeze)
> + setbits32(&guts->devdisr, mask);
> + else
> + clrbits32(&guts->devdisr, mask);
> +
> + in_be32(&guts->devdisr);
> +}
> +
> +static void mpc85xx_give_timebase(void)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> +
> + while (!tb_req)
> + barrier();
I think tb_req and tb_valid need to be 'volatile'.
> + tb_req = 0;
> +
> + mpc85xx_timebase_freeze(1);
> + timebase = get_tb();
> + mb();
> + tb_valid = 1;
> +
> + while (tb_valid)
> + barrier();
> +
> + mpc85xx_timebase_freeze(0);
> +
> + local_irq_restore(flags);
> +}
> +
> +static void mpc85xx_take_timebase(void)
> +{
> + unsigned long flags;
> +
> + local_irq_save(flags);
> +
> + tb_req = 1;
> + while (!tb_valid)
> + barrier();
> +
> + set_tb(timebase >> 32, timebase & 0x);
> + isync();
> + tb_valid = 0;
> +
> + local_irq_restore(flags);
> +}
> +#endif
> +
> static int __init
> smp_85xx_kick_cpu(int nr)
> {
> @@ -228,6 +292,16 @@ smp_85xx_setup_cpu(int cpu_nr)
> doorbell_setup_this_cpu();
> }
>
> +static const struct of_device_id mpc85xx_smp_guts_ids[] = {
> + { .compatible = "fsl,mpc8572-guts", },
> + { .compatible = "fsl,p1020-guts", },
> + { .compatible = "fsl,p1021-guts", },
> + { .compatible = "fsl,p1022-guts", },
> + { .compatible = "fsl,p1023-guts", },
> + { .compatible = "fsl,p2020-guts", },
> + {},
> +};
I wonder if it's possible to dynamically generate the compatible
string by using the SOC name?
> +
> void __init mpc85xx_smp_init(void)
> {
> struct device_node *np;
> @@ -249,6 +323,16 @@ void __init mpc85xx_smp_init(void)
> smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
> }
>
> + np = of_find_matching_node(NULL, mpc85xx_smp_guts_ids);
> + if (np) {
> +#ifdef C
Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.
On Wed, May 2, 2012 at 8:16 PM, David Daney wrote: > From: David Daney > > This code has been working well for about six months on a couple of > different configurations (boards), so I thought it would be a good > time to send it out again, and I hope get it on the path towards > merging. David, I'm trying to implement this feature on our boards, which don't use GPIOs but rather a memory-mapped FPGA. I control the mux by setting some bits in one of the FPGA registers. Do you have a real device tree I can use as an example? I'm not sure what the "parent" MDIO bus node is supposed to represent. Is that that device that actually controls the muxing hardware, which in our case would be the FPGA? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Re: Build regressions/improvements in v3.4-rc7
On Thu, May 17, 2012 at 12:30 PM, Timur Tabi wrote: > Anyway, I think I see what the problem is, but it does appear when I use > the normal defconfigs. What .config was being used? I meant to say that it does NOT appear. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/mpc85xx: p1022ds support the MTD for NOR and NAND flash
On Mon, Apr 16, 2012 at 8:42 PM, wrote: > From: Jerry Huang > > The compatilbe 'simple-bus' is removed from the latest DTS for NAND and > NOR flash partition, so we must add the new compatilbe support for p1022ds, > otherwise, the kernel can't parse the partition of NOR and NAND flash. > > Signed-off-by: Jerry Huang > --- This patch is no longer compatible with the upstream kernel since my patch, "powerpc/85xx: don't call of_platform_bus_probe() twice" was applied. This is because my patch removed p1022_ds_ids[]. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/p1022ds/DTS: Add RTC support
On Mon, Apr 16, 2012 at 8:42 PM, wrote: > From: Jerry Huang > > Add the RTC support for p1022ds > > Signed-off-by: Jerry Huang > --- Acked-by: Timur Tabi Kumar, please apply for 3.5. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/2] powerpc/mpc85xx: support the MTD for p1022ds flash
On Tue, Apr 17, 2012 at 4:15 AM, wrote:
> diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c
> b/arch/powerpc/platforms/85xx/p1022_ds.c
> index e74b7cd..0db3a7e 100644
> --- a/arch/powerpc/platforms/85xx/p1022_ds.c
> +++ b/arch/powerpc/platforms/85xx/p1022_ds.c
> @@ -463,6 +463,7 @@ static void __init p1022_ds_setup_arch(void)
> static struct of_device_id __initdata p1022_ds_ids[] = {
> /* So that the DMA channel nodes can be probed individually: */
> { .compatible = "fsl,eloplus-dma", },
> + { .compatible = "fsl,p1022-elbc", },
> {},
> };
Have you actually tested this with an upstream kernel? p1022_ds_ids[]
is broken upstream, so adding a new line won't work.
Take a look at http://patchwork.ozlabs.org/patch/128533/
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
Ping! Kumar, you forgot to deal with this patch for 3.3. The window for 3.4 is closing rapidly. There are no objections to my patch. Could you please apply it and get it merged into 3.4? I'm tired of waiting. On Thu, Mar 29, 2012 at 4:47 PM, Tabi Timur-B04825 wrote: > On Thu, Mar 29, 2012 at 3:44 PM, Kumar Gala wrote: >> >> A few minor bug fixes and missing dts updates for 3.4. There got lost in >> the mix. Sorry for the delay > > What about my "don't call of_platform_bus_probe() twice" patch? > That's still an important fix for the P1022DS. > > -- > Timur Tabi > Linux kernel developer at Freescale -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Thu, Mar 29, 2012 at 3:44 PM, Kumar Gala wrote: > > A few minor bug fixes and missing dts updates for 3.4. There got lost in > the mix. Sorry for the delay What about my "don't call of_platform_bus_probe() twice" patch? That's still an important fix for the P1022DS. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: why use 'raw_spin_lock_irqsave' inf function 'of_find_node_with_property'
On Thu, Mar 29, 2012 at 5:01 AM, Huang Changming-R66093
wrote:
> Hi, all
>
> In function “of_find_node_with_property”, why use “raw_spin_lock_irqsave” to
> disable preemption and disable interrupt?
Where do you see raw_spin_lock_irqsave?
struct device_node *of_find_node_with_property(struct device_node *from,
const char *prop_name)
{
struct device_node *np;
struct property *pp;
read_lock(&devtree_lock);
np = from ? from->allnext : allnodes;
for (; np; np = np->allnext) {
for (pp = np->properties; pp != 0; pp = pp->next) {
if (of_prop_cmp(pp->name, prop_name) == 0) {
of_node_get(np);
goto out;
}
}
}
out:
of_node_put(from);
read_unlock(&devtree_lock);
return np;
}
We need a lock so that we don't parse the tree while it's being
modified. That would cause the for-loop to fail in strange ways.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: issues calling of_platform_bus_probe() twice
Grant Likely wrote: > That's because you're using it wrong. of_platform_bus_probe() creates > platform devices at the starting level and every level below it as > described by the bus ids. It is illegal to call of_platform_bus_probe() > twice at the same level in the DT. Well, *I* am not using it wrong. Notice that my patch fixes (or works around) the commit that *did* do it wrong: http://patchwork.ozlabs.org/patch/126289/ -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: issues calling of_platform_bus_probe() twice
Benjamin Herrenschmidt wrote: > Why don't you track down the actual bug instead ? I was hoping that someone who is very familiar with the code would take a look. I don't know the OF layer that well. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Device Tree Bindings for Freescale TDM controller
On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812 wrote: > >> > + compatible = "fsl,p1010-tdm", "fsl,mpc8315-tdm"; >> > + reg = <0x16000 0x200 0x2c000 0x2000>; >> > + clock-frequency = <0>; >> >> Show a real clock-frequency, perhaps with a comment saying it's typically >> filled in by boot software. > Okay. Scott, are you suggesting that Poonam put a non-zero number in the DTS for clock-frequency? If so, then I don't think that's a good idea, if U-Boot will always override it. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Device Tree Bindings for Freescale TDM controller
On Sat, Mar 17, 2012 at 2:33 AM, Aggrwal Poonam-B10812 wrote: > >> > + - clock-frequency >> > + Usage: optional >> > + Value type: >> > + Definition: The frequency at which the TDM block is operating. >> >> Will this frequency ever need to be > 4GHz? > Don't think so, at max this will be CCB, not sure if CCB on our platforms may > get bigger than 4G ever. Apparently, 4GB is the new 640K. In Poonam's defense, every clock frequency property in the device tree is a 32-bit integer. I've never seen a 64-bit one. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] mpc85xx_defconfig:Added I2C_CHARDEV option in defconfig to have compiled I2C device interface
On Sat, Mar 17, 2012 at 4:00 AM, Shaveta Leekha wrote: > Signed-off-by: Shaveta Leekha > --- Where's the patch description? You need to explain WHY this change is a good idea. And you should change all defconfigs in one patch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: issues calling of_platform_bus_probe() twice
Grant Likely wrote: >>> > > Are you aware of any reason that we can't call of_platform_bus_probe() >>> > > or multiple times. Timur's run into an issue in which all devices >>> > > don't get registered properly if we call of_platform_bus_probe() times >>> > > with different of_device_id struct's. >> > >> > Nothing comes to mind... Grant ? > Neither for me. Should work. I posted a work-around patch here: http://patchwork.ozlabs.org/patch/128533/ Without this patch, drivers cannot probe on DMA *channels*, or any other grandchildren of the root node. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/9] powerpc/mpc8548cds: Add FPGA node to dts
On Tue, Mar 6, 2012 at 3:06 AM, Zhao Chenhui wrote: > From: chenhui zhao > > Remove FPGA(CADMUS) macros in code. Move it to dts. > > Signed-off-by: Zhao Chenhui > Signed-off-by: Li Yang > --- Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/e500: make load_up_spe a normal fuction
On Mon, Feb 27, 2012 at 4:59 AM, Olivia Yin wrote: > So that we can call it in kernel. And why would we want that? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Li Yang-R58472 wrote: > It's a good point. Why can't we decide to use 32-bit/36-bit TLB at runtime > even for e500v2? That's not what PHYS_64BIT does. PHYS_64BIT determines whether phys_addr_t is a u64 or a u32. This is something that must be determined at compilation time. >> Please remember that the Kconfig for the P1022DS already forced >> PHYS_64BIT for all mpc85xx platforms. All we're doing is making it >> possible to deselect PHYS_64BIT. > > I think it's a side-effect introduced by P1022DS support and need to be fixed. Exactly. That's what these patches do. And these patches have been applied to the SDK. I'm just waiting for Kumar to apply them to his repository. > There was no mentioning of enforcing 36-bit for all mpc85xx platforms. It's not enforcing, it's just the default. If you build with mpc85xx_smp_defconfig, then you'll get a 36-bit kernel. But now you can also use menuconfig to turn off PHYS_64BIT. Before these fixes, that was not possible. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Li Yang-R58472 wrote: > The mpc85xx_defconfig does include silicons with e500v1 core which > doesn't have the 36-bit support. Won't enabling 36-bit support by > default break the support for them? No. The kernel will detect at runtime that that it's an e500v1 core and it won't try to create 36-bit TLBs. (e.g. it won't write to MAS7). Please remember that the Kconfig for the P1022DS already forced PHYS_64BIT for all mpc85xx platforms. All we're doing is making it possible to deselect PHYS_64BIT. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Huang Changming-R66093 wrote: > I want to know if you have the other codes for different address? > > The current U-boot just detect the base address of DTS and the CCSR address. > If they are different, u-boot will print the warning and return 0, > so the kernel can't been booted. I had a patch that verified some PCI addresses (which are sometimes slightly mismatched), but Kumar rejected it. I could add some more checks, but the 90% of the time, the only problem is using the wrong size (32-bit vs 36-bit) DT. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Li Yang-R58472 wrote: > Even though the user still need to know the addressing mode that u-boot > is using. It won't work if the addressing mode of u-boot and device > tree are different. U-Boot will tell the user if the DT does not match. I added code to U-Boot to do that. So if you have a 36-bit U-Boot and a 32-bit DT, then you will get a warning. If you have a 36-bit U-boot and a 36-bit DT and a 32-bit kernel, you will get nothing. But if you have a 32-bit U-boot and a 32-bit DT and a 36-bit kernel, then that will work. A 36-bit kernel works with 32-bit *and* 36-bit DTs. This is why a 36-bit kernel should be the default. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Li Yang-R58472 wrote: > I agree with Changming that we shouldn't setting PHYS_64BIT by default. The default kernel should always be the compatible with as much as possible. Disabling PHYS_64BIT by default means that the default kernel will not work with a 36-bit DTS. If you attempt to boot such a kernel with a 36-bit DTS, there will be no text output. Most people will not know why it's not working. So the safest option is for PHYS_64BIT to be enabled by default. That way, the kernel will always work. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: allow CONFIG_PHYS_64BIT to be selectable
Huang Changming-R66093 wrote: > I have one similar patch to remove the "select PHYS_64BIT". > http://patchwork.ozlabs.org/patch/132351/ That one doesn't update the defconfigs, which means that the default kernel will not have PHYS_64BIT enabled. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: warnings from drivers/tty/ehv_bytechan.c
Stephen Rothwell wrote: > console_initcall() is not defined for modules. Hmmm... the patch you posted is a good short-term fix, but I wonder if makes sense for the driver to support modules at all. I have this in the driver: #include ... module_init(ehv_bc_init); module_exit(ehv_bc_exit); although to be honest, I can't remember the last time I tried to compile it as a module. The problem stems from the fact that it's a console driver *and* a tty driver. It makes sense that a tty driver can be compiled as a module, but not a console driver. So Greg, can I do something like this: #ifdef MODULE module_initcall(ehv_bc_console_init) #else console_initcall(ehv_bc_console_init); #endif -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 21/30] KVM: PPC: make e500v2 and e500mc mutually exclusive
On Fri, Feb 17, 2012 at 10:56 AM, Alexander Graf wrote: > config KVM_E500MC > bool "KVM support for PowerPC E500MC/E5500 processors" > - depends on EXPERIMENTAL && PPC_E500MC > + depends on EXPERIMENTAL && PPC_E500MC && !KVM_E500V2 There was a patch floating around that made a similar change to the platform support, so that you could either build an e500v2 kernel and enable support only for e500v2 board, or you could build an e500mc kernel and enable support only for e500mc boards. Last I heard, the patch wasn't quite working, but that was a while ago. Is there a connection between this patch and that one? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx:Add PSC9131 RDB Support
On Tue, Feb 14, 2012 at 2:37 AM, Prabhakar Kushwaha wrote: > > Applied on git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git > branch next This is actually a false statement. "Applied" is past tense, so you are saying that this patch has *already* been applied to Kumar's powerpc.git repository. But this is not true -- Kumar's repository has not been updated in the last three weeks, and this patch is nowhere to be found. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v5] powerpc/85xx: Abstract common define of signal multiplex control for qe
On Wed, Feb 15, 2012 at 12:58 AM, Zhicheng Fan wrote:
> @@ -114,6 +114,24 @@ struct ccsr_guts_86xx {
> __be32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
> } __attribute__ ((packed));
>
> +#ifdef CONFIG_PPC_85xx
> +
Remove this #ifdef. It doesn't really help, and it makes things more
complicated.
> +/* Alternate function signal multiplex control */
> +#define MPC85xx_PMUXCR_QE0 0x8000
> +#define MPC85xx_PMUXCR_QE2 0x2000
> +#define MPC85xx_PMUXCR_QE3 0x1000
> +#define MPC85xx_PMUXCR_QE4 0x0800
> +#define MPC85xx_PMUXCR_QE5 0x0400
> +#define MPC85xx_PMUXCR_QE6 0x0200
> +#define MPC85xx_PMUXCR_QE7 0x0100
> +#define MPC85xx_PMUXCR_QE8 0x0080
> +#define MPC85xx_PMUXCR_QE9 0x0040
> +#define MPC85xx_PMUXCR_QE10 0x0020
> +#define MPC85xx_PMUXCR_QE11 0x0010
> +#define MPC85xx_PMUXCR_QE12 0x0008
#define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
> + pr_err("mpc85xx-rdb: could not map global
> utilties register!\n");
No exclamation marks (!) in kernel messages.
You misspelled "utilities".
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
On Thu, Feb 16, 2012 at 7:27 PM, Kumar Gala wrote: > For some of these platforms like P2041RDB, P3041DS, P3060QDS, P4080DS, & > P5020DS only a 36-bit physical address map is supported by u-boot and the > device tree. This was a decision that was made to NOT support 32-bit address > map for these boards and accept the performance implication of it to reduce > the # of builds, etc. Was this a Freescale internal decision, or is this a generic 85xx decision? For the record, I'm in favor in leaving out support for 32-bit address map in the upstream kernel, and having it be an option on the SDK only. However, in order to do that, we cannot have "select PHYS_64BIT" in the Kconfigs. It needs to be in the defconfigs instead. Putting it in the defconfig will eliminate the need to have it in every Kconfig block, so I think that's an improvement. Then the SDK can include a defconfig that does not have PHYS_64BIT defined. And the SDK can include 32-bit U-Boots and 32-bit device trees for any board where Freescale determines there is a need. I think Leo's patch simplifies things for everyone. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v4] powerpc/85xx: Add p1025rdb platform support
On Tue, Feb 14, 2012 at 2:06 AM, Zhicheng Fan wrote: > From: Zhicheng Fan > > Signed-off-by: Zhicheng Fan > --- Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v4] powerpc/dts: Add dts for p1025rdb board
On Tue, Feb 14, 2012 at 2:06 AM, Zhicheng Fan wrote: > From: Zhicheng Fan > > P1025RDB Overview > -- > 1Gbyte DDR3 SDRAM > 32 Mbyte NAND flash > 16Mbyte NOR flash > 16 Mbyte SPI flash > SD connector to interface with the SD memory card > Real-time clock on I2C bus > > PCIe: > - x1 PCIe slot > - x1 mini-PCIe slot > > 10/100/1000 BaseT Ethernet ports: > - eTSEC1, RGMII: one 10/100/1000 port using AtherosTM AR8021 > - eTSEC2, SGMII: one 10/100/1000 port using VitesseTM VSC8221 > - eTSEC3, RGMII: one 10/100/1000 port using AtherosTM AR8021 > > USB 2.0 port: > - Two USB2.0 Type A receptacles > - One USB2.0 signal to Mini PCIe slot > > Dual RJ45 UART ports: > - DUART interface: supports two UARTs up to 115200 bps for console display > > Signed-off-by: Zhicheng Fan > --- Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v5] powerpc/85xx: Add Quicc Engine support for p1025rdb
On Wed, Feb 15, 2012 at 12:58 AM, Zhicheng Fan wrote: > From: Zhicheng Fan > > Signed-off-by: Zhicheng Fan > --- Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/1] fsldma: ignore end of segments interrupt
On Thu, Jan 26, 2012 at 2:58 PM, Ira W. Snyder wrote: > The mpc8349ea has been observed to generate spurious end of segments > interrupts despite the fact that they are not enabled by this driver. > Check for them and ignore them to avoid a kernel error message. When this happens, are there any other status bits set? It seems weird that there are spurious interrupts from an internal block, especially since it's the same block on all 83xx parts. I wonder if the EOSI bit just happens to be set when the interrupt occurs for some other reason. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
On Thu, Feb 16, 2012 at 6:10 AM, Li Yang wrote: > > The reason why we need to keep PHYS_64BIT option configurable is > that enabling it cause negative performance impact on various > aspects like TLB miss and physical address manipulating. We should > not enable it unless really needed, e.g. use large memory of 4GB > or bigger. I think we should make 36-bit the only option for the upstream defconfigs, and if we want a 32-bit "optimized" kernel for the SDK, then we provide that on the SDK only. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/85xx: fix problem that prevents PHYS_64BIT from configurable
On Thu, Feb 16, 2012 at 9:56 AM, Tabi Timur-B04825 wrote: > I think we should make 36-bit the only option for the upstream > defconfigs, and if we want a 32-bit "optimized" kernel for the SDK, > then we provide that on the SDK only. Oops, I meant to post this as a reply to "powerpc/85xx: add a 36-bit corenet default config". -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v3] powerpc/dts: Add dts for p1025rdb board
On Fri, Feb 10, 2012 at 4:18 AM, Zhicheng Fan wrote: > > + local-mac-address = [ 00 00 00 00 00 00 ]; This doesn't belong in the DTS. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v3] powerpc/85xx: Abstract common define of signal multiplex control for qe
On Sun, Feb 12, 2012 at 11:33 PM, Zhicheng Fan wrote:
> if (np) {
> - pmuxcr = of_iomap(np, 0) + MPC85xx_PMUXCR_OFFSET;
> + guts = of_iomap(np, 0);
>
> - if (!pmuxcr)
> - printk(KERN_EMERG "Error: Alternate function"
> - " signal multiplex control register
> not"
> - " mapped!\n");
> + if (!guts)
> + pr_err("mpc85xx-rdb: could not map global
> utilties register!\n");
> else
> /* P1021 has pins muxed for QE and other functions. To
> * enable QE UEC mode, we need to set bit QE0 for UCC1
> @@ -291,11 +286,11 @@ static void __init mpc85xx_mds_qe_init(void)
> * and QE12 for QE MII management signals in PMUXCR
> * register.
> */
> - setbits32(pmuxcr, MPC85xx_PMUXCR_QE0 |
> + setbits32(&guts->pmuxcr, MPC85xx_PMUXCR_QE0 |
> MPC85xx_PMUXCR_QE3 |
> MPC85xx_PMUXCR_QE9 |
> MPC85xx_PMUXCR_QE12);
> -
> + iounmap(guts);
This needs to move into the "else" statement:
else {
setbits(...
iounmap( ...)
}
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v3] powerpc/85xx: Add Quicc Engine support for p1025rdb
On Sun, Feb 12, 2012 at 11:33 PM, Zhicheng Fan wrote:
> From: Zhicheng Fan
>
> Signed-off-by: Zhicheng Fan
> ---
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 78
> -
> 1 files changed, 77 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> index e95aef7..c9dfdcc 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> @@ -26,6 +26,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include
> #include
> @@ -47,6 +50,10 @@ void __init mpc85xx_rdb_pic_init(void)
> struct mpic *mpic;
> unsigned long root = of_get_flat_dt_root();
>
> +#ifdef CONFIG_QUICC_ENGINE
> + struct device_node *np;
> +#endif
> +
> if (of_flat_dt_is_compatible(root, "fsl,MPC85XXRDB-CAMP")) {
> mpic = mpic_alloc(NULL, 0,
> MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS |
> @@ -62,6 +69,18 @@ void __init mpc85xx_rdb_pic_init(void)
>
> BUG_ON(mpic == NULL);
> mpic_init(mpic);
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> + if (np) {
> + qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> + qe_ic_cascade_high_mpic);
> + of_node_put(np);
> +
> + } else
> + pr_err("%s: Could not find qe-ic node\n", __func__);
> +#endif
> +
> }
>
> /*
> @@ -69,7 +88,7 @@ void __init mpc85xx_rdb_pic_init(void)
> */
> static void __init mpc85xx_rdb_setup_arch(void)
> {
> -#ifdef CONFIG_PCI
> +#if defined(CONFIG_PCI) || defined(CONFIG_QUICC_ENGINE)
> struct device_node *np;
> #endif
>
> @@ -85,6 +104,63 @@ static void __init mpc85xx_rdb_setup_arch(void)
> #endif
>
> mpc85xx_smp_init();
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!np) {
> + pr_err("%s: Could not find Quicc Engine node\n", __func__);
> + goto qe_fail;
> + }
> +
> + qe_reset();
> + of_node_put(np);
> +
> + np = of_find_node_by_name(NULL, "par_io");
> + if (np) {
> + struct device_node *ucc;
> +
> + par_io_init(np);
> + of_node_put(np);
> +
> + for_each_node_by_name(ucc, "ucc")
> + par_io_of_config(ucc);
> +
> + }
> + if (machine_is(p1025_rdb)) {
> +
> + struct ccsr_guts_85xx __iomem *guts;
> +
> + np = of_find_node_by_name(NULL, "global-utilities");
> + if (np) {
> +
> + guts = of_iomap(np, 0);
> + if (!guts) {
> +
> + pr_err("mpc85xx-rdb: could not map global
> utilties register!\n");
> +
> + } else {
> +#if defined(CONFIG_UCC_GETH) || defined(CONFIG_SERIAL_QE)
This #if should be above the " if (machine_is(p1025_rdb)) {" line.
> + /* P1025 has pins muxed for QE and other functions. To
> + * enable QE UEC mode, we need to set bit QE0 for UCC1
> + * in Eth mode, QE0 and QE3 for UCC5 in Eth mode, QE9
> + * and QE12 for QE MII management singals in PMUXCR
> + * register.
> + */
> + setbits32(&guts->pmuxcr, MPC85xx_PMUXCR_QE0 |
> + MPC85xx_PMUXCR_QE3 |
> + MPC85xx_PMUXCR_QE9 |
> + MPC85xx_PMUXCR_QE12);
> +#endif
> + }
> + iounmap(guts);
Put the iounmap() call inside the "else" bracket:
setbits32(&guts->pmuxcr, MPC85xx_PMUXCR_QE0 |
MPC85xx_PMUXCR_QE3 |
MPC85xx_PMUXCR_QE9 |
MPC85xx_PMUXCR_QE12);
iounmap(guts);
}
You're not really paying attention to the code that you're writing.
Please take a good look at your code before you paste it.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v2] P1025RDB: Add Quicc Engine support
> +#ifdef CONFIG_QUICC_ENGINE
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> + if (np) {
> + qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> + qe_ic_cascade_high_mpic);
> + of_node_put(np);
> +
> + } else
> + pr_err("Could not find qe-ic node\n");
Since you have to use pr_err instead of dev_err, please add a prefix
to the message. Like this:
pr_err("mpc85xx-rdb: could not find qe-ic node\n");
or maybe something like this:
pr_err("%s: could not find qe-ic node\n", __func__);
> + if (machine_is(p1025_rdb)) {
> +
> + __be32 __iomem *pmuxcr;
> +
> + np = of_find_node_by_name(NULL, "global-utilities");
> +
> + if (np) {
> + pmuxcr = of_iomap(np, 0) + MPC85xx_PMUXCR_OFFSET;
Use the ccsr_guts_85xx structure instead of hard-coded offsets.
MPC85xx_PMUXCR_OFFSET should be deleted.
> +
> + if (!pmuxcr)
> + pr_err(KERN_EMERG "Error: Alternate function"
> + " signal multiplex control register
> not"
> + " mapped!\n");
A missing node in the device tree is NOT an emergency. Also, the
KERN_xxx macros are not supposed to be used in a pr_xxx macro. Please
don't blindly copy/paste code from somewhere else without thinking
about it.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2 v4] powerpc/85xx: Add p1020rdb-pc platform support
On Wed, Feb 8, 2012 at 11:40 PM, Zhicheng Fan wrote:
> +static int __init p1020_rdb_pc_probe(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> +
> + if (of_flat_dt_is_compatible(root, "fsl,P1020RDB-PC"))
> + return 1;
> + return 0;
> +}
static int __init p1020_rdb_pc_probe(void)
{
unsigned long root = of_get_flat_dt_root();
return of_flat_dt_is_compatible(root, "fsl,P1020RDB-PC");
}
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2 v4] powerpc/dts: Add dts for p1020rdb-pc board
On Wed, Feb 8, 2012 at 11:40 PM, Zhicheng Fan wrote: > > arch/powerpc/boot/dts/p1020rdb-pc.dts | 90 > arch/powerpc/boot/dts/p1020rdb-pc.dtsi | 247 > ++ > arch/powerpc/boot/dts/p1020rdb-pc_36b.dts | 90 If we're going to support both 32-bit and 36-bit dts files, then we have to label both DTS files properly. Do not assume that 32-bit is the "default", because on some platforms, 36-bit is the default. p1020rdb-pc.dts should be called p1020rdb-pc_32b.dts. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/dts: Removed fsl,msi property from dts.
On Thu, Feb 9, 2012 at 7:41 AM, Diana Craciun wrote: > From: Diana CRACIUN > > The association in the decice tree between PCI and MSI > using fsl,msi property was an artificial one and it does > not reflect the actual hardware. > > Signed-off-by: Diana CRACIUN Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Efika (mpc5200b): sound doesn't build/work from linux-2.6.38.x
On Fri, Feb 3, 2012 at 8:02 PM, acrux wrote: > as i said [1] it seems to be fixed only in 3.x instead the last working one > is the obsolete 2.6.36.x . > Anyway, alog the sound/soc/fsl/mpc5200_dma.c now builds the sound is still > broken. Ok, I missed that part in your email. The Efika sound driver was not being compiled by default for a very long time, so I think everyone just forgot about it. I posted a patch to enable it by default and fix the compilation errors, but I'm pretty sure that it's succumbed to bit rot. ALSA has changed, especially with the introduction of device trees, and so now someone needs to fix the Efika driver. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Efika (mpc5200b): sound doesn't build/work from linux-2.6.38.x
On Thu, Feb 2, 2012 at 10:57 AM, acrux wrote: > well, i got the same error with also linux-2.6.37. Btw, this was already > reported about a year ago: > http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088415.html I think this was fixed already. You're using an obsolete kernel. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Abstract common define of signal multiplex control for qe
fanzc wrote: >> >>> Signed-off-by: Fanzc >> Please fix this. There are only two e's in freescale. In addition, >> please use your full name. >> > Hi Timur, > >You mean that need to remove the define to other file or create new > file? No, I mean you're signed-off-by should be this: Signed-off-by: Zhicheng Fan -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc: Abstract common define of signal multiplex control for qe
On Thu, Jan 19, 2012 at 11:00 PM, Zhicheng Fan wrote: > Signed-off-by: Fanzc Please fix this. There are only two e's in freescale. In addition, please use your full name. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] P1025RDB: add Quicc Engine support
On Thu, Jan 19, 2012 at 11:00 PM, Zhicheng Fan wrote:
> From: Fanzc
>
> Signed-off-by: Fanzc
Please use your full name (first and last name)
> ---
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 79
> -
> 1 files changed, 78 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> index 1950076..1ba67aa 100644
> --- a/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> +++ b/arch/powerpc/platforms/85xx/mpc85xx_rdb.c
> @@ -26,6 +26,9 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
>
> #include
> #include
> @@ -47,6 +50,10 @@ void __init mpc85xx_rdb_pic_init(void)
> struct mpic *mpic;
> unsigned long root = of_get_flat_dt_root();
>
> +#ifdef CONFIG_QUICC_ENGINE
> + struct device_node *np;
> +#endif
> +
> if (of_flat_dt_is_compatible(root, "fsl,MPC85XXRDB-CAMP")) {
> mpic = mpic_alloc(NULL, 0,
> MPIC_BIG_ENDIAN | MPIC_BROKEN_FRR_NIRQS |
> @@ -62,6 +69,18 @@ void __init mpc85xx_rdb_pic_init(void)
>
> BUG_ON(mpic == NULL);
> mpic_init(mpic);
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe-ic");
> + if (np) {
> + qe_ic_init(np, 0, qe_ic_cascade_low_mpic,
> + qe_ic_cascade_high_mpic);
> + of_node_put(np);
> +
> + } else
> + printk(KERN_ERR "Could not find qe-ic node\n");
Use pr_err instead of printk(KERN_ERR
> +#endif
> +
> }
>
> /*
> @@ -69,7 +88,7 @@ void __init mpc85xx_rdb_pic_init(void)
> */
> static void __init mpc85xx_rdb_setup_arch(void)
> {
> -#ifdef CONFIG_PCI
> +#if defined(CONFIG_PCI) || defined(CONFIG_QUICC_ENGINE)
> struct device_node *np;
> #endif
>
> @@ -85,6 +104,64 @@ static void __init mpc85xx_rdb_setup_arch(void)
> #endif
>
> mpc85xx_smp_init();
> +
> +#ifdef CONFIG_QUICC_ENGINE
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!np) {
> + printk(KERN_ERR "Could not find Quicc Engine node\n");
> + goto qe_fail;
> + }
> +
> + qe_reset();
> + of_node_put(np);
> +
> + np = of_find_node_by_name(NULL, "par_io");
> + if (np) {
> + struct device_node *ucc;
> +
> + par_io_init(np);
> + of_node_put(np);
> +
> + for_each_node_by_name(ucc, "ucc")
> + par_io_of_config(ucc);
> +
> + }
> + if (machine_is(p1025_rdb)) {
> +
> + __be32 __iomem *pmuxcr;
> +
> + np = of_find_node_by_name(NULL, "global-utilities");
> +
> + if (np) {
> + pmuxcr = of_iomap(np, 0) + MPC85xx_PMUXCR_OFFSET;
You're missing the iounmap().
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
Michael Neuling wrote: > In message<4f1370c9.9010...@freescale.com> you wrote: >> Michael Neuling wrote: >>> Fix a bunch of compiler errors and warnings introduced in: >>> commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0 >>> Author: Timur Tabi >>> drivers/video: fsl-diu-fb: merge all allocated data into one block >>> >>> Signed-off-by: Michael Neuling >>> --- >>> Timur: you do compile test your patches, right? :-P >> >> I have a script that tests each commit in a set to make sure it compiles, >> so that git-bisect isn't broken. > > May I suggest you actually run the script next time :-P Tomorrow, when I get into the office, I'll take a look. But my code has always compiled. Can you give me the output of your compiler? > diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c > index acf292b..3006b2b 100644 > --- a/drivers/video/fsl-diu-fb.c > +++ b/drivers/video/fsl-diu-fb.c > @@ -1432,7 +1432,7 @@ static int fsl_diu_suspend(struct platform_device > *ofdev, pm_message_t state) > struct fsl_diu_data *data; > > data = dev_get_drvdata(&ofdev->dev); > - disable_lcdc(data->fsl_diu_info[0]); > + disable_lcdc(&(data->fsl_diu_info[0])); > > return 0; > } > @@ -1442,7 +1442,7 @@ static int fsl_diu_resume(struct platform_device *ofdev) > struct fsl_diu_data *data; > > data = dev_get_drvdata(&ofdev->dev); > - enable_lcdc(data->fsl_diu_info[0]); > + enable_lcdc(&(data->fsl_diu_info[0])); I prefer this: disable_lcdc(data->fsl_diu_info); Your change makes sense. I don't understand why it compiles on my system. Something strange is going on. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] drivers/video: compile fixes for fsl-diu-fb.c
Michael Neuling wrote:
> Fix a bunch of compiler errors and warnings introduced in:
>commit ddd3d905436b572ebadc09dcf2d12ca5b37020a0
>Author: Timur Tabi
>drivers/video: fsl-diu-fb: merge all allocated data into one block
>
> Signed-off-by: Michael Neuling
> ---
> Timur: you do compile test your patches, right? :-P
I have a script that tests each commit in a set to make sure it compiles,
so that git-bisect isn't broken.
> This is effecting mpc85xx_defconfig on mainline (and has been in
> linux-next for while already).
>
> diff --git a/drivers/video/fsl-diu-fb.c b/drivers/video/fsl-diu-fb.c
> index acf292b..78cac52 100644
> --- a/drivers/video/fsl-diu-fb.c
> +++ b/drivers/video/fsl-diu-fb.c
> @@ -366,7 +366,7 @@ struct mfb_info {
>*/
> struct fsl_diu_data {
> dma_addr_t dma_addr;
> - struct fb_info fsl_diu_info[NUM_AOIS];
> + struct fb_info *fsl_diu_info[NUM_AOIS];
This doesn't make any sense. If you change fsl_diu_info into a pointer,
then where is the object being allocated?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] DTS: fix the bug and add the chip compatible for eSDHC
On Fri, Dec 23, 2011 at 12:10 AM, wrote: > > Accordint to latest kernel, the auto-cmd12 property should be > "sdhci,auto-cmd12", and according to the SDHC binding and the workaround for > the special chip, add the chip compatible for eSDHC: "fsl,p1022-esdhc", > "fsl,mpc8536-esdhc", "fsl,p2020-esdhc" and "fsl,p1010-esdhc". Please do not use the phrase "fix the bug" in patch summaries. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Linux port availability for p5010 processor
On Thu, Dec 15, 2011 at 5:45 AM, Vineeth wrote: > > why is it a part of 85xx directory ? the core of P5020 is E5500 where the > core of 85xx is e500; e5500 is very similar to e500, so it's all part of the same family of cores. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix compile error with 85xx/p1022_ds.c
On Sun, Dec 11, 2011 at 4:49 PM, Michael Neuling wrote: > Current linux-next compiled with mpc85xx_defconfig causes this: > arch/powerpc/platforms/85xx/p1022_ds.c:341:14: error: 'udbg_progress' > undeclared here (not in a function) > > Add include to fix this. > > Signed-off-by: Michael Neuling Acked-by: Timur Tabi -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add MSI support for the Freescale hypervisor
Scott Wood wrote: > How's the hypervisor even going to know if the mem= kernel command line > argument is used to change the end of main memory (assuming that's been > taken into account by this point in the boot sequence)? > > What if the user put a shared memory region immediately after the main > partition memory? Alright, I'll need to add support for detached MSIIR addresses, but for now I think this patch is okay. It's the same level of functionality that we provide on the SDK. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/fsl: add MSI support for the Freescale hypervisor
Scott Wood wrote: > Technically, it's up to the hv config file where MSIIR gets mapped. > After main memory is just a common way of configuring it, but won't work > if we're limiting the partition's memory to end at an unusual address. I'll change the comment to reflect this. Why can't we have the hypervisor always put MSIIR at the end of DDR, and not make it configurable? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 10/13] powerpc: Update mpc85xx/corenet 32-bit defconfigs
On Mon, Oct 10, 2011 at 3:50 PM, Becky Bruce wrote: > From: Becky Bruce > > Results from updates via make savedefconfig. > > Signed-off-by: Becky Bruce > --- ... > -CONFIG_PPC_EPAPR_HV_BYTECHAN=y I guess no one noticed that this patch removes byte channel support, thereby preventing this kernel from booting under the hypervisor? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix compiliation with hugetlbfs enabled
On Thu, Nov 24, 2011 at 1:40 PM, Kumar Gala wrote: > arch/powerpc/mm/hugetlbpage.c: In function 'reserve_hugetlb_gpages': > arch/powerpc/mm/hugetlbpage.c:312:2: error: implicit declaration of function > 'parse_args' > > Signed-off-by: Kumar Gala Acked-by: Timur Tabi Would you please apply this to your 'next' branch? It won't compile with this patch. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
