* Re: [PATCH v2 00/12] memory-hotplug: hot-remove physical memory
From: Ni zhan Chen @ 2012-10-23 10:30 UTC (permalink / raw)
To: wency
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <1350988250-31294-1-git-send-email-wency@cn.fujitsu.com>
On 10/23/2012 06:30 PM, wency@cn.fujitsu.com wrote:
> From: Wen Congyang <wency@cn.fujitsu.com>
The patchset doesn't support kernel memory hot-remove, correct? If the
answer is yes, you should point out in your patchset changelog.
>
> The patch-set was divided from following thread's patch-set.
>
> https://lkml.org/lkml/2012/9/5/201
>
> The last version of this patchset:
> https://lkml.org/lkml/2012/10/5/469
>
> If you want to know the reason, please read following thread.
>
> https://lkml.org/lkml/2012/10/2/83
>
> The patch-set has only the function of kernel core side for physical
> memory hot remove. So if you use the patch, please apply following
> patches.
>
> - bug fix for memory hot remove
> https://lkml.org/lkml/2012/10/19/56
>
> - acpi framework
> https://lkml.org/lkml/2012/10/19/156
>
> The patches can free/remove the following things:
>
> - /sys/firmware/memmap/X/{end, start, type} : [PATCH 2/10]
> - mem_section and related sysfs files : [PATCH 3-4/10]
> - memmap of sparse-vmemmap : [PATCH 5-7/10]
> - page table of removed memory : [RFC PATCH 8/10]
> - node and related sysfs files : [RFC PATCH 9-10/10]
>
> * [PATCH 2/10] checks whether the memory can be removed or not.
>
> If you find lack of function for physical memory hot-remove, please let me
> know.
>
> How to test this patchset?
> 1. apply this patchset and build the kernel. MEMORY_HOTPLUG, MEMORY_HOTREMOVE,
> ACPI_HOTPLUG_MEMORY must be selected.
> 2. load the module acpi_memhotplug
> 3. hotplug the memory device(it depends on your hardware)
> You will see the memory device under the directory /sys/bus/acpi/devices/.
> Its name is PNP0C80:XX.
> 4. online/offline pages provided by this memory device
> You can write online/offline to /sys/devices/system/memory/memoryX/state to
> online/offline pages provided by this memory device
> 5. hotremove the memory device
> You can hotremove the memory device by the hardware, or writing 1 to
> /sys/bus/acpi/devices/PNP0C80:XX/eject.
>
> Note: if the memory provided by the memory device is used by the kernel, it
> can't be offlined. It is not a bug.
>
> Known problems:
> 1. hotremoving memory device may cause kernel panicked
> This bug will be fixed by Liu Jiang's patch:
> https://lkml.org/lkml/2012/7/3/1
>
>
> Changelogs from v1 to v2:
> Patch1: new patch, offline memory twice. 1st iterate: offline every non primary
> memory block. 2nd iterate: offline primary (i.e. first added) memory
> block.
>
> Patch3: new patch, no logical change, just remove reduntant codes.
>
> Patch9: merge the patch from wujianguo into this patch. flush tlb on all cpu
> after the pagetable is changed.
>
> Patch12: new patch, free node_data when a node is offlined
>
> Wen Congyang (6):
> memory-hotplug: try to offline the memory twice to avoid dependence
> memory-hotplug: remove redundant codes
> memory-hotplug: introduce new function arch_remove_memory() for
> removing page table depends on architecture
> memory-hotplug: remove page table of x86_64 architecture
> memory-hotplug: remove sysfs file of node
> memory-hotplug: free node_data when a node is offlined
>
> Yasuaki Ishimatsu (6):
> memory-hotplug: check whether all memory blocks are offlined or not
> when removing memory
> memory-hotplug: remove /sys/firmware/memmap/X sysfs
> memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
> memory-hotplug: implement register_page_bootmem_info_section of
> sparse-vmemmap
> memory-hotplug: remove memmap of sparse-vmemmap
> memory-hotplug: memory_hotplug: clear zone when removing the memory
>
> arch/ia64/mm/discontig.c | 14 ++
> arch/ia64/mm/init.c | 18 ++
> arch/powerpc/mm/init_64.c | 14 ++
> arch/powerpc/mm/mem.c | 12 +
> arch/s390/mm/init.c | 12 +
> arch/s390/mm/vmem.c | 14 ++
> arch/sh/mm/init.c | 17 ++
> arch/sparc/mm/init_64.c | 14 ++
> arch/tile/mm/init.c | 8 +
> arch/x86/include/asm/pgtable_types.h | 1 +
> arch/x86/mm/init_32.c | 12 +
> arch/x86/mm/init_64.c | 409 ++++++++++++++++++++++++++++++++++
> arch/x86/mm/pageattr.c | 47 ++--
> drivers/acpi/acpi_memhotplug.c | 8 +-
> drivers/base/memory.c | 6 +
> drivers/firmware/memmap.c | 98 ++++++++-
> include/linux/firmware-map.h | 6 +
> include/linux/memory_hotplug.h | 15 +-
> include/linux/mm.h | 5 +-
> mm/memory_hotplug.c | 409 ++++++++++++++++++++++++++++++++--
> mm/sparse.c | 5 +-
> 21 files changed, 1087 insertions(+), 57 deletions(-)
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
^ permalink raw reply
* Re: [PATCH v2 00/12] memory-hotplug: hot-remove physical memory
From: Wen Congyang @ 2012-10-23 10:39 UTC (permalink / raw)
To: Ni zhan Chen
Cc: linux-s390, linux-ia64, len.brown, linux-acpi, linux-sh, x86,
linux-kernel, cmetcalf, linux-mm, isimatu.yasuaki, paulus,
minchan.kim, kosaki.motohiro, rientjes, sparclinux, cl,
linuxppc-dev, akpm, liuj97
In-Reply-To: <508671AD.6000704@gmail.com>
At 10/23/2012 06:30 PM, Ni zhan Chen Wrote:
> On 10/23/2012 06:30 PM, wency@cn.fujitsu.com wrote:
>> From: Wen Congyang <wency@cn.fujitsu.com>
>
> The patchset doesn't support kernel memory hot-remove, correct? If the
> answer is yes, you should point out in your patchset changelog.
The answer is no. If you only apply this patchset, you only can hotremove
the memory by SCI. If you want to hotremove it by writing 1 to the file
/sys/bus/acpi/devices/PNP0C80:XX/eject, you should apply the following
patchset:
https://lkml.org/lkml/2012/10/19/156
Thanks
Wen Congyang
>
>>
>> The patch-set was divided from following thread's patch-set.
>>
>> https://lkml.org/lkml/2012/9/5/201
>>
>> The last version of this patchset:
>> https://lkml.org/lkml/2012/10/5/469
>>
>> If you want to know the reason, please read following thread.
>>
>> https://lkml.org/lkml/2012/10/2/83
>>
>> The patch-set has only the function of kernel core side for physical
>> memory hot remove. So if you use the patch, please apply following
>> patches.
>>
>> - bug fix for memory hot remove
>> https://lkml.org/lkml/2012/10/19/56
>> - acpi framework
>> https://lkml.org/lkml/2012/10/19/156
>>
>> The patches can free/remove the following things:
>>
>> - /sys/firmware/memmap/X/{end, start, type} : [PATCH 2/10]
>> - mem_section and related sysfs files : [PATCH 3-4/10]
>> - memmap of sparse-vmemmap : [PATCH 5-7/10]
>> - page table of removed memory : [RFC PATCH 8/10]
>> - node and related sysfs files : [RFC PATCH 9-10/10]
>>
>> * [PATCH 2/10] checks whether the memory can be removed or not.
>>
>> If you find lack of function for physical memory hot-remove, please
>> let me
>> know.
>>
>> How to test this patchset?
>> 1. apply this patchset and build the kernel. MEMORY_HOTPLUG,
>> MEMORY_HOTREMOVE,
>> ACPI_HOTPLUG_MEMORY must be selected.
>> 2. load the module acpi_memhotplug
>> 3. hotplug the memory device(it depends on your hardware)
>> You will see the memory device under the directory
>> /sys/bus/acpi/devices/.
>> Its name is PNP0C80:XX.
>> 4. online/offline pages provided by this memory device
>> You can write online/offline to
>> /sys/devices/system/memory/memoryX/state to
>> online/offline pages provided by this memory device
>> 5. hotremove the memory device
>> You can hotremove the memory device by the hardware, or writing 1 to
>> /sys/bus/acpi/devices/PNP0C80:XX/eject.
>>
>> Note: if the memory provided by the memory device is used by the
>> kernel, it
>> can't be offlined. It is not a bug.
>>
>> Known problems:
>> 1. hotremoving memory device may cause kernel panicked
>> This bug will be fixed by Liu Jiang's patch:
>> https://lkml.org/lkml/2012/7/3/1
>>
>>
>> Changelogs from v1 to v2:
>> Patch1: new patch, offline memory twice. 1st iterate: offline every
>> non primary
>> memory block. 2nd iterate: offline primary (i.e. first
>> added) memory
>> block.
>>
>> Patch3: new patch, no logical change, just remove reduntant codes.
>>
>> Patch9: merge the patch from wujianguo into this patch. flush tlb on
>> all cpu
>> after the pagetable is changed.
>>
>> Patch12: new patch, free node_data when a node is offlined
>>
>> Wen Congyang (6):
>> memory-hotplug: try to offline the memory twice to avoid dependence
>> memory-hotplug: remove redundant codes
>> memory-hotplug: introduce new function arch_remove_memory() for
>> removing page table depends on architecture
>> memory-hotplug: remove page table of x86_64 architecture
>> memory-hotplug: remove sysfs file of node
>> memory-hotplug: free node_data when a node is offlined
>>
>> Yasuaki Ishimatsu (6):
>> memory-hotplug: check whether all memory blocks are offlined or not
>> when removing memory
>> memory-hotplug: remove /sys/firmware/memmap/X sysfs
>> memory-hotplug: unregister memory section on SPARSEMEM_VMEMMAP
>> memory-hotplug: implement register_page_bootmem_info_section of
>> sparse-vmemmap
>> memory-hotplug: remove memmap of sparse-vmemmap
>> memory-hotplug: memory_hotplug: clear zone when removing the memory
>>
>> arch/ia64/mm/discontig.c | 14 ++
>> arch/ia64/mm/init.c | 18 ++
>> arch/powerpc/mm/init_64.c | 14 ++
>> arch/powerpc/mm/mem.c | 12 +
>> arch/s390/mm/init.c | 12 +
>> arch/s390/mm/vmem.c | 14 ++
>> arch/sh/mm/init.c | 17 ++
>> arch/sparc/mm/init_64.c | 14 ++
>> arch/tile/mm/init.c | 8 +
>> arch/x86/include/asm/pgtable_types.h | 1 +
>> arch/x86/mm/init_32.c | 12 +
>> arch/x86/mm/init_64.c | 409
>> ++++++++++++++++++++++++++++++++++
>> arch/x86/mm/pageattr.c | 47 ++--
>> drivers/acpi/acpi_memhotplug.c | 8 +-
>> drivers/base/memory.c | 6 +
>> drivers/firmware/memmap.c | 98 ++++++++-
>> include/linux/firmware-map.h | 6 +
>> include/linux/memory_hotplug.h | 15 +-
>> include/linux/mm.h | 5 +-
>> mm/memory_hotplug.c | 409
>> ++++++++++++++++++++++++++++++++--
>> mm/sparse.c | 5 +-
>> 21 files changed, 1087 insertions(+), 57 deletions(-)
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@kvack.org. For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>>
>
>
^ permalink raw reply
* RE: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Sethi Varun-B16395 @ 2012-10-23 11:32 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: joerg.roedel@amd.com, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <6AE080B68D46FC4BA2D2769E68D765B7081084A7@039-SN2MPN1-023.039d.mgd.msft.net>
> -----Original Message-----
> From: Tabi Timur-B04825
> Sent: Tuesday, October 23, 2012 2:48 AM
> To: Sethi Varun-B16395
> Cc: joerg.roedel@amd.com; iommu@lists.linux-foundation.org; linuxppc-
> dev@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU
> API implementation.
>=20
> On Wed, Oct 17, 2012 at 12:32 PM, Varun Sethi <Varun.Sethi@freescale.com>
> wrote:
>=20
> > + * Copyright (C) 2012 Freescale Semiconductor, Inc.
>=20
> Copyright 2012 Freescale Semiconductor, Inc.
>=20
[Sethi Varun-B16395] Have followed similar convention elsewhere i.e. added =
(C).
> > + *
> > + */
> > +
> > +#include <linux/init.h>
> > +#include <linux/iommu.h>
> > +#include <linux/slab.h>
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/mm.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/device.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/bootmem.h>
> > +#include <linux/genalloc.h>
> > +#include <asm/io.h>
> > +#include <asm/bitops.h>
> > +
> > +#include "fsl_pamu.h"
> > +
> > +/* PAMU bypass enbale register contains control bits for
> > + * enabling bypass mode on each PAMU.
> > + */
>=20
> /*
> * Linux multi-line comments
> * look like this.
> */
>=20
> > +#define PAMUBYPENR 0x604
>=20
> Update struct ccsr_guts instead.
>=20
> http://patchwork.ozlabs.org/patch/141649/
>=20
[Sethi Varun-B16395] Ok.
> > +
> > +/* define indexes for each operation mapping scenario */
> > +#define OMI_QMAN 0x00
> > +#define OMI_FMAN 0x01
> > +#define OMI_QMAN_PRIV 0x02
> > +#define OMI_CAAM 0x03
> > +
> > +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");
>=20
> pr_err("fsl-pamu: PPAACT has not been initialized\n");
>=20
> Make sure ALL pr_xxx() messages in this file start with "fsl-pamu: "
>=20
> > + return NULL;
> > + }
> > +
> > + return &ppaact[liodn];
>=20
> Bounds checking?
>=20
[Sethi Varun-B16395] Ok.
> > +}
> > +
> > +/** 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 =3D pamu_get_ppaace(liodn);
> > + if (!ppaace)
> > + return -ENOENT;
>=20
> error message?
[Sethi Varun-B16395] Have error messages at places from where the function =
is invoked.
>=20
> > +
> > + 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 |=3D 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
>=20
> This is not proper kerneldoc format.
[Sethi Varun-B16395] What format must be used? Can you point me to a releva=
nt file.
>=20
> > + */
> > +int pamu_disable_liodn(int liodn)
> > +{
> > + paace_t *ppaace;
> > +
> > + ppaace =3D pamu_get_ppaace(liodn);
> > + if (!ppaace)
> > + return -ENOENT;
>=20
> error message?
[Sethi Varun-B16395] Error message at the point of invocation.
>=20
> > +
> > + 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];
>=20
> bounds checking?
>=20
[Sethi Varun-B16395] Ok.
> > +}
> > +
> > +static unsigned long pamu_get_fspi_and_allocate(u32 subwin_cnt) {
>=20
> subwin_cnt should probably be an unsigned int.
[Sethi Varun-B16395] Why?
>=20
> This function needs to be documented. What value is being returned?
>=20
> > + unsigned long spaace_addr;
> > +
> > + spaace_addr =3D gen_pool_alloc(spaace_pool, subwin_cnt *
> sizeof(paace_t));
> > + if (!spaace_addr)
> > + return ULONG_MAX;
>=20
> What's wrong with returning 0 on error?
>=20
> > +
> > + return (spaace_addr - (unsigned long)spaact) /
> > + (sizeof(paace_t));
>=20
> Is this supposed to be a virtual address? If so, then return void*
> instead of an unsigned long.
>=20
[Sethi Varun-B16395] No, the function returns an fspi index is the spaace t=
able.
> > +}
> > +
> > +void pamu_free_subwins(int liodn)
> > +{
> > + paace_t *ppaace;
> > + u32 subwin_cnt, size;
>=20
> subwin_cnt should probably be an unsigned int.
>
[Sethi Varun-B16395] Why?
=20
> > +
> > + ppaace =3D pamu_get_ppaace(liodn);
> > + if (!ppaace)
> > + return;
>=20
> error message
[Sethi Varun-B16395] Ok.
>=20
> > +
> > + if (get_bf(ppaace->addr_bitfields, PPAACE_AF_MW)) {
> > + subwin_cnt =3D 1UL << (get_bf(ppaace->impl_attr,
> PAACE_IA_WCE) + 1);
> > + size =3D (subwin_cnt - 1) * sizeof(paace_t);
> > + gen_pool_free(spaace_pool, (unsigned
> long)&spaact[ppaace->fspi], size);
> > + set_bf(ppaace->addr_bitfields, PPAACE_AF_MW, 0);
> > + }
> > +}
> > +
> > +/* Function used for updating stash destination for the coresspong
> LIODN.
> > + */
> > +int pamu_update_paace_stash(int liodn, u32 subwin, u32 value) {
> > + paace_t *paace;
> > +
> > + paace =3D pamu_get_ppaace(liodn);
> > + if (!paace) {
> > + return -ENOENT;
> > + }
>=20
> Error message?
>=20
[Sethi Varun-B16395] Ok.
> > + if (subwin) {
> > + paace =3D pamu_get_spaace(paace->fspi, subwin - 1);
> > + if (!paace) {
> > + return -ENOENT;
>=20
> Error message?
[Sethi Varun-B16395] Ok.
>=20
>=20
> > + }
> > + }
> > + set_bf(paace->impl_attr, PAACE_IA_CID, value);
> > +
> > + return 0;
> > +}
> > +
> > +/** Sets up PPAACE entry for specified liodn
> > + *
> > + * @param[in] liodn Logical IO device number
> > + * @param[in] win_addr starting address of DSA window
> > + * @param[in] win-size size of DSA window
> > + * @param[in] omi Operation mapping index -- if ~omi =3D=3D 0 t=
hen
> omi not defined
> > + * @param[in] rpn real (true physical) page number
> > + * @param[in] stashid cache stash id for associated cpu -- if
> ~stashid =3D=3D 0 then
> > + * stashid not defined
> > + * @param[in] snoopid snoop id for hardware coherency -- if
> ~snoopid =3D=3D 0 then
> > + * snoopid not defined
> > + * @param[in] subwin_cnt number of sub-windows
> > + * @param[in] prot window permissions
> > + *
> > + * @return Returns 0 upon success else error code < 0 returned */
>=20
> Please provide proper kerneldoc comments for all of the functions in this
> file.
>=20
> > +int pamu_config_ppaace(int liodn, phys_addr_t win_addr, phys_addr_t
> win_size,
> > + u32 omi, unsigned long rpn, u32 snoopid, u32
> stashid,
> > + u32 subwin_cnt, int prot) {
> > + paace_t *ppaace;
> > + unsigned long fspi;
> > +
> > + if ((win_size & (win_size - 1)) || win_size < PAMU_PAGE_SIZE) {
> > + pr_err("window size too small or not a power of two
> %llx\n", win_size);
> > + return -EINVAL;
> > + }
> > +
> > + if (win_addr & (win_size - 1)) {
> > + pr_err("window address is not aligned with window
> size\n");
> > + return -EINVAL;
> > + }
> > +
> > + ppaace =3D pamu_get_ppaace(liodn);
> > + if (!ppaace) {
> > + return -ENOENT;
> > + }
> > +
> > + /* window size is 2^(WSE+1) bytes */
> > + set_bf(ppaace->addr_bitfields, PPAACE_AF_WSE,
> > + map_addrspace_size_to_wse(win_size));
> > +
> > + pamu_setup_default_xfer_to_host_ppaace(ppaace);
> > +
> > + ppaace->wbah =3D win_addr >> (PAMU_PAGE_SHIFT + 20);
> > + set_bf(ppaace->addr_bitfields, PPAACE_AF_WBAL,
> > + (win_addr >> PAMU_PAGE_SHIFT));
> > +
> > + /* set up operation mapping if it's configured */
> > + if (omi < OME_NUMBER_ENTRIES) {
> > + set_bf(ppaace->impl_attr, PAACE_IA_OTM,
> PAACE_OTM_INDEXED);
> > + ppaace->op_encode.index_ot.omi =3D omi;
> > + } else if (~omi !=3D 0) {
> > + pr_err("bad operation mapping index: %d\n", omi);
> > + return -EINVAL;
> > + }
> > +
> > + /* configure stash id */
> > + if (~stashid !=3D 0)
> > + set_bf(ppaace->impl_attr, PAACE_IA_CID, stashid);
> > +
> > + /* configure snoop id */
> > + if (~snoopid !=3D 0)
> > + ppaace->domain_attr.to_host.snpid =3D snoopid;
> > +
> > + if (subwin_cnt) {
> > + /* The first entry is in the primary PAACE instead */
> > + fspi =3D pamu_get_fspi_and_allocate(subwin_cnt - 1);
> > + if (fspi =3D=3D ULONG_MAX) {
> > + pr_err("spaace indexes exhausted\n");
> > + return -EINVAL;
> > + }
>=20
> Indentation problem.
>
[Sethi Varun-B16395] Ok.
=20
> > +
> > + /* window count is 2^(WCE+1) bytes */
> > + set_bf(ppaace->impl_attr, PAACE_IA_WCE,
> > + map_subwindow_cnt_to_wce(subwin_cnt));
> > + set_bf(ppaace->addr_bitfields, PPAACE_AF_MW, 0x1);
> > + ppaace->fspi =3D fspi;
> > + } else {
> > + set_bf(ppaace->impl_attr, PAACE_IA_ATM,
> PAACE_ATM_WINDOW_XLATE);
> > + ppaace->twbah =3D rpn >> 20;
> > + set_bf(ppaace->win_bitfields, PAACE_WIN_TWBAL, rpn);
> > + set_bf(ppaace->addr_bitfields, PAACE_AF_AP, prot);
> > + set_bf(ppaace->impl_attr, PAACE_IA_WCE, 0);
> > + set_bf(ppaace->addr_bitfields, PPAACE_AF_MW, 0);
> > + }
> > + mb();
> > +
> > + return 0;
> > +}
> > +
> > +/** Sets up SPAACE entry for specified subwindow
> > + *
> > + * @param[in] liodn Logical IO device number
> > + * @param[in] subwin_cnt number of sub-windows associated with
> > +dma-window
> > + * @param[in] subwin_addr starting address of subwindow
> > + * @param[in] subwin_size size of subwindow
> > + * @param[in] omi Operation mapping index
> > + * @param[in] rpn real (true physical) page number
> > + * @param[in] snoopid snoop id for hardware coherency -- if
> ~snoopid =3D=3D 0 then
> > + * snoopid not defined
> > + * @param[in] stashid cache stash id for associated cpu
> > + * @param[in] enable enable/disable subwindow after
> reconfiguration
> > + * @param[in] prot sub window permissions
> > + *
> > + * @return Returns 0 upon success else error code < 0 returned */
> > +int pamu_config_spaace(int liodn, u32 subwin_cnt, u32 subwin_addr,
> > + phys_addr_t subwin_size, u32 omi, unsigned long
> rpn,
> > + u32 snoopid, u32 stashid, int enable, int prot)
> > +{
> > + paace_t *paace;
> > + unsigned long fspi;
> > +
> > + /* setup sub-windows */
> > + if (!subwin_cnt) {
> > + pr_err("Invalid subwindow count\n");
> > + return -EINVAL;
> > + }
> > +
> > + paace =3D pamu_get_ppaace(liodn);
> > + if (subwin_addr > 0 && paace) {
> > + fspi =3D paace->fspi;
> > + paace =3D pamu_get_spaace(fspi, subwin_addr - 1);
> > +
> > + if (paace && !(paace->addr_bitfields & PAACE_V_VALID))
> {
> > + pamu_setup_default_xfer_to_host_spaace(paace);
> > + set_bf(paace->addr_bitfields, SPAACE_AF_LIODN,
> liodn);
> > + }
> > + }
> > +
> > + if (!paace)
> > + return -ENOENT;
>=20
> Error message?
>=20
[Sethi Varun-B16395] Error message in the invoking function.
> > +
> > + if (!enable && prot =3D=3D PAACE_AP_PERMS_DENIED) {
> > + if (subwin_addr > 0)
> > + set_bf(paace->addr_bitfields, PAACE_AF_V,
> > + PAACE_V_INVALID);
> > + else
> > + set_bf(paace->addr_bitfields, PAACE_AF_AP,
> > + prot);
> > + mb();
> > + return 0;
> > + }
> > +
> > + if (subwin_size & (subwin_size - 1) || subwin_size <
> PAMU_PAGE_SIZE) {
> > + pr_err("subwindow size out of range, or not a power of
> 2\n");
> > + return -EINVAL;
> > + }
> > +
> > + if (rpn =3D=3D ULONG_MAX) {
> > + pr_err("real page number out of range\n");
> > + return -EINVAL;
> > + }
> > +
> > + /* window size is 2^(WSE+1) bytes */
> > + set_bf(paace->win_bitfields, PAACE_WIN_SWSE,
> > + map_addrspace_size_to_wse(subwin_size));
> > +
> > + set_bf(paace->impl_attr, PAACE_IA_ATM, PAACE_ATM_WINDOW_XLATE);
> > + paace->twbah =3D rpn >> 20;
> > + set_bf(paace->win_bitfields, PAACE_WIN_TWBAL, rpn);
> > + set_bf(paace->addr_bitfields, PAACE_AF_AP, prot);
> > +
> > + /* configure snoop id */
> > + if (~snoopid !=3D 0)
> > + paace->domain_attr.to_host.snpid =3D snoopid;
> > +
> > + /* set up operation mapping if it's configured */
> > + if (omi < OME_NUMBER_ENTRIES) {
> > + set_bf(paace->impl_attr, PAACE_IA_OTM,
> PAACE_OTM_INDEXED);
> > + paace->op_encode.index_ot.omi =3D omi;
> > + } else if (~omi !=3D 0) {
> > + pr_err("bad operation mapping index: %d\n", omi);
> > + return -EINVAL;
> > + }
> > +
> > + if (~stashid !=3D 0)
> > + set_bf(paace->impl_attr, PAACE_IA_CID, stashid);
> > +
> > + smp_wmb();
> > +
> > + if (enable)
> > + paace->addr_bitfields |=3D PAACE_V_VALID;
> > +
> > + mb();
> > +
> > + return 0;
> > +}
> > +
> > +void get_ome_index(u32 *omi_index, struct device *dev) {
> > + if (of_device_is_compatible(dev->of_node, "fsl,qman-portal"))
> > + *omi_index =3D OMI_QMAN;
> > + if (of_device_is_compatible(dev->of_node, "fsl,qman"))
> > + *omi_index =3D OMI_QMAN_PRIV; }
>=20
> Documentation?
>=20
> > +
> > +u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
>=20
> Can we make the stash_id a signed integer, and return -1 as an error?
> Making it a u32 is awkward because we keep doing stuff like this:
>=20
> if (~stashid !=3D 0)
>=20
> and
>=20
> return ~(u32)0;
[Sethi Varun-B16395] What's wrong with this?
>=20
> > +{
> > + const u32 *prop;
> > + struct device_node *node;
> > + u32 cache_level;
> > + int len;
> > +
> > + /* Fastpath, exit early if L3/CPC cache is target for stashing
> */
> > + if (stash_dest_hint =3D=3D IOMMU_ATTR_CACHE_L3) {
> > + node =3D of_find_compatible_node(NULL, NULL,
> > + "fsl,p4080-l3-cache-controller");
> > + if (node) {
>=20
> if (!node) {
> pr_err( "no cpc node" );
> return ~(u32)0;
> }
>=20
> > + prop =3D of_get_property(node, "cache-stash-id"=
,
> 0);
> > + if (!prop) {
> > + pr_err("missing cache-stash-id at
> %s\n", node->full_name);
> > + of_node_put(node);
> > + return ~(u32)0;
> > + }
> > + of_node_put(node);
> > + return be32_to_cpup(prop);
> > + }
> > + return ~(u32)0;
> > + }
> > +
> > + for_each_node_by_type(node, "cpu") {
> > + prop =3D of_get_property(node, "reg", &len);
> > + if (be32_to_cpup(prop) =3D=3D vcpu)
> > + break;
> > + }
> > +
> > + /* find the hwnode that represents the cache */
> > + for (cache_level =3D IOMMU_ATTR_CACHE_L1; cache_level <=3D
> > + IOMMU_ATTR_CACHE_L3; cache_level++) {
>=20
> Shouldn't this be < IOMMU_ATTR_CACHE_L3, since we already handled the CPC
> case above?
[Sethi Varun-B16395] Yes
>=20
> > + if (stash_dest_hint =3D=3D cache_level) {
> > + prop =3D of_get_property(node, "cache-stash-id"=
,
> 0);
> > + if (!prop) {
> > + pr_err("missing cache-stash-id at
> %s\n", node->full_name);
> > + of_node_put(node);
> > + return ~(u32)0;
> > + }
> > + of_node_put(node);
> > + return be32_to_cpup(prop);
> > + }
> > +
> > + prop =3D of_get_property(node, "next-level-cache", 0);
> > + if (!prop) {
> > + pr_err("can't find next-level-cache at %s\n",
> > + node->full_name);
> > + of_node_put(node);
> > + return ~(u32)0; /* can't traverse any further
> */
> > + }
> > + of_node_put(node);
> > +
> > + /* advance to next node in cache hierarchy */
> > + node =3D of_find_node_by_phandle(*prop);
> > + if (!node) {
> > + pr_err("bad cpu reference %d\n", vcpu);
>=20
> print the full path of any node that has a broken property
>=20
[Sethi Varun-B16395] Ok.
> > + return ~(u32)0;
> > + }
> > + }
> > +
> > + pr_err("stash dest not found for %d on vcpu %d\n",
> > + stash_dest_hint, vcpu);
> > + return ~(u32)0;
> > +}
> > +
> > +#define QMAN_PAACE 1
> > +#define QMAN_PORTAL_PAACE 2
> > +#define BMAN_PAACE 3
>=20
> Documentation?
[Sethi Varun-B16395] Ok.
>=20
> > +
> > +static void setup_qbman_paace(paace_t *ppaace, int paace_type) {
> > + switch(paace_type) {
> > + case QMAN_PAACE:
> > + set_bf(ppaace->impl_attr, PAACE_IA_OTM,
> PAACE_OTM_INDEXED);
> > + ppaace->op_encode.index_ot.omi =3D OMI_QMAN_PRI=
V;
> > + /* setup QMAN Private data stashing for the L3
> cache */
> > + set_bf(ppaace->impl_attr, PAACE_IA_CID,
> get_stash_id(IOMMU_ATTR_CACHE_L3, 0));
> > + set_bf(ppaace-
> >domain_attr.to_host.coherency_required, PAACE_DA_HOST_CR,
> > + 0);
> > + break;
> > + case QMAN_PORTAL_PAACE:
> > + set_bf(ppaace->impl_attr, PAACE_IA_OTM,
> PAACE_OTM_INDEXED);
> > + ppaace->op_encode.index_ot.omi =3D OMI_QMAN;
> > + /*Set DQRR and Frame stashing for the L3 cache
> */
> > + set_bf(ppaace->impl_attr, PAACE_IA_CID,
> get_stash_id(IOMMU_ATTR_CACHE_L3, 0));
> > + break;
> > + case BMAN_PAACE:
> > + set_bf(ppaace-
> >domain_attr.to_host.coherency_required, PAACE_DA_HOST_CR,
> > + 0);
> > + break;
> > + }
> > +}
>=20
> Seriously, you need to document these functions.
>=20
> > +
> > +static void __init setup_omt(struct ome *omt) {
> > + struct ome *ome;
> > +
> > + /* Configure OMI_QMAN */
> > + ome =3D &omt[OMI_QMAN];
> > +
> > + ome->moe[IOE_READ_IDX] =3D EOE_VALID | EOE_READ;
> > + ome->moe[IOE_EREAD0_IDX] =3D EOE_VALID | EOE_RSA;
> > + ome->moe[IOE_WRITE_IDX] =3D EOE_VALID | EOE_WRITE;
> > + ome->moe[IOE_EWRITE0_IDX] =3D EOE_VALID | EOE_WWSAO;
> > +
> > + ome->moe[IOE_DIRECT0_IDX] =3D EOE_VALID | EOE_LDEC;
> > + ome->moe[IOE_DIRECT1_IDX] =3D EOE_VALID | EOE_LDECPE;
> > +
> > + /* Configure OMI_FMAN */
> > + ome =3D &omt[OMI_FMAN];
> > + ome->moe[IOE_READ_IDX] =3D EOE_VALID | EOE_READI;
> > + ome->moe[IOE_WRITE_IDX] =3D EOE_VALID | EOE_WRITE;
> > +
> > + /* Configure OMI_QMAN private */
> > + ome =3D &omt[OMI_QMAN_PRIV];
> > + ome->moe[IOE_READ_IDX] =3D EOE_VALID | EOE_READ;
> > + ome->moe[IOE_WRITE_IDX] =3D EOE_VALID | EOE_WRITE;
> > + ome->moe[IOE_EREAD0_IDX] =3D EOE_VALID | EOE_RSA;
> > + ome->moe[IOE_EWRITE0_IDX] =3D EOE_VALID | EOE_WWSA;
> > +
> > + /* Configure OMI_CAAM */
> > + ome =3D &omt[OMI_CAAM];
> > + ome->moe[IOE_READ_IDX] =3D EOE_VALID | EOE_READI;
> > + ome->moe[IOE_WRITE_IDX] =3D EOE_VALID | EOE_WRITE; }
> > +
> > +int setup_one_pamu(unsigned long pamu_reg_base, unsigned long
> pamu_reg_size,
> > + phys_addr_t ppaact_phys, phys_addr_t spaact_phys,
> > + phys_addr_t omt_phys) {
> > + u32 *pc;
> > + struct pamu_mmap_regs *pamu_regs;
> > + u32 pc3_val;
> > +
> > + pc3_val =3D in_be32((u32 *)(pamu_reg_base + PAMU_PC3));
>=20
> pamu_reg_base should be a void*. Or even better, create a struct.
>=20
> > +
> > +#define PAMU_PAGE_SHIFT 12
> > +#define PAMU_PAGE_SIZE 4096ULL
>=20
> 4096ULL? Why not just 4096?
>=20
>=20
> > +
> > +/* This bitmap advertises the page sizes supported by PAMU hardware
> > + * to the IOMMU API.
> > + */
> > +#define FSL_PAMU_PGSIZES (~0xFFFUL)
>=20
> There should be a better way to define this. ~(PAMU_PAGE_SIZE-1) maybe?
[Sethi Varun-B16395] For 32 bit systems with current iommu_map implementati=
on we can't=20
create a PAMU window > 2G. =20
>=20
>=20
> > +
> > +static int map_liodn(int liodn, struct fsl_dma_domain *dma_domain) {
> > + u32 subwin_cnt =3D dma_domain->subwin_cnt;
> > + unsigned long rpn;
> > + int ret =3D 0, i;
> > +
> > + if (subwin_cnt) {
> > + struct dma_subwindow *sub_win_ptr =3D
> > + &dma_domain->sub_win_arr[0];
> > + for (i =3D 0; i < subwin_cnt; i++) {
> > + if (sub_win_ptr[i].valid) {
> > + rpn =3D sub_win_ptr[i].paddr >>
> > + PAMU_PAGE_SHIFT,
> > + spin_lock(&iommu_lock);
> > + ret =3D pamu_config_spaace(liodn,
> subwin_cnt, i,
> > +
> sub_win_ptr[i].size,
> > + -1,
> > + rpn,
> > + dma_domain-
> >snoop_id,
> > + dma_domain-
> >stash_id,
> > + (i > 0) ? 1 :
> 0,
> > +
> sub_win_ptr[i].prot);
> > + spin_unlock(&iommu_lock);
> > + if (ret) {
> > + pr_err("PAMU SPAACE
> configuration failed for liodn %d\n",
> > + liodn);
> > + return ret;
> > + }
> > + }
> > + }
> > + } else {
> > +
>=20
> Blank line
>=20
>=20
> > +
> > +
> > +static struct fsl_dma_domain *iommu_alloc_dma_domain(void) {
> > + struct fsl_dma_domain *domain;
> > +
> > + domain =3D kmem_cache_zalloc(fsl_pamu_domain_cache, GFP_KERNEL)=
;
> > + if (!domain)
> > + return NULL;
> > +
> > + domain->stash_id =3D -1;
> > + domain->snoop_id =3D -1;
>=20
> Here, stash_id is set to -1, but in other places, you use ~0. Please be
> consistent.
[Sethi Varun-B16395] Will fix this.
>=20
> > +
> > + INIT_LIST_HEAD(&domain->devices);
> > +
> > + spin_lock_init(&domain->domain_lock);
> > +
> > + return domain;
> > +}
> > +
> > +static inline struct fsl_dma_domain *find_domain(struct device *dev)
> > +{
> > + return dev->archdata.iommu_domain; }
> > +
> > +static void remove_domain_ref(struct device_domain_info *info, u32
> > +subwin_cnt) {
> > + list_del(&info->link);
> > + spin_lock(&iommu_lock);
> > + if (subwin_cnt)
> > + pamu_free_subwins(info->liodn);
> > + pamu_disable_liodn(info->liodn);
> > + spin_unlock(&iommu_lock);
> > + spin_lock(&device_domain_lock);
> > + info->dev->archdata.iommu_domain =3D NULL;
> > + free_devinfo_mem(info);
> > + spin_unlock(&device_domain_lock); }
> > +
> > +static void destroy_domain(struct fsl_dma_domain *dma_domain) {
> > + struct device_domain_info *info;
> > +
>=20
> > + while (!list_empty(&dma_domain->devices)) {
> > + info =3D list_entry(dma_domain->devices.next,
> > + struct device_domain_info, link);
> > + remove_domain_ref(info, dma_domain->subwin_cnt);
> > + }
>=20
> I wonder if you should use list_for_each_safe() instead.
>=20
>=20
[Sethi Varun-B16395] Why? we are destroying the domain here.
> > +
> > +static int get_subwin_cnt(dma_addr_t geom_size, u32 subwin, u32
> > +*subwin_cnt) {
> > +
>=20
> blank line
>=20
> > + switch (subwin) {
> > + case 0:
> > + /* We can't support geometry size > 1MB*/
> > + if (geom_size !=3D 1024 * 1024)
>=20
> Instead of doing 1024*1024, use math that reflects the hardware
> limitation of the PAMU: 256 * PAMU_PAGE_SIZE. Create a macro for 256,
> like PAMU_MAX_SUBWINDOWS or something.
>=20
[Sethi Varun-B16395] Ok.
> > + return 0;
> > + *subwin_cnt =3D 256;
> > + break;
> > + case 1:
> > + /* No subwindows only a single PAMU window */
> > + *subwin_cnt =3D 0;
> > + break;
> > + default:
> > + if (subwin > max_subwindow_count ||
> > + (subwin & (subwin - 1)))
> > + return 0;
> > + *subwin_cnt =3D subwin;
> > + }
> > + return 1;
> > +}
> > +
> > +static int configure_domain_geometry(struct iommu_domain *domain,
> > +void *data) {
> > + int ret =3D 0;
>=20
> I don't think you need to initialize 'ret'
>=20
>=20
> > +}
> > +
> > +static int configure_domain_dma_state(struct fsl_dma_domain
> > +*dma_domain, int enable)
>=20
> bool enable
>=20
[Sethi Varun-B16395] Ok.
> Finally, please CC: me on all IOMMU and PAMU patches you post upstream.
>
[Sethi Varun-B16395] Sure.
-Varun
^ permalink raw reply
* RE: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU API implementation.
From: Sethi Varun-B16395 @ 2012-10-23 11:35 UTC (permalink / raw)
To: Wood Scott-B07421, Tabi Timur-B04825
Cc: joerg.roedel@amd.com, iommu@lists.linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
In-Reply-To: <1350949982.30970.11@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Tuesday, October 23, 2012 5:23 AM
> To: Tabi Timur-B04825
> Cc: Sethi Varun-B16395; joerg.roedel@amd.com; iommu@lists.linux-
> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH 3/3 v3] iommu/fsl: Freescale PAMU driver and IOMMU
> API implementation.
>=20
> On 10/22/2012 04:18:07 PM, Tabi Timur-B04825 wrote:
> > On Wed, Oct 17, 2012 at 12:32 PM, Varun Sethi
> > <Varun.Sethi@freescale.com> wrote:
> > > +}
> > > +
> > > +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?
>=20
> spaact offset (yes, this needs to be documented)
[Sethi Varun-B16395] Ok.
>=20
> > > +/* This bitmap advertises the page sizes supported by PAMU hardware
> > > + * to the IOMMU API.
> > > + */
> > > +#define FSL_PAMU_PGSIZES (~0xFFFUL)
> >
> > There should be a better way to define this. ~(PAMU_PAGE_SIZE-1)
> > maybe?
>=20
> Is it even true? We don't support IOMMU pages larger than the SoC can
> address.
>=20
> The (~0xFFFUL) version also discards some valid IOMMU page sizes on 32-
> bit kernels. One use case for windows larger than the CPU virtual
> address space is creating one big identity-map window to effectively
> disable translation. If we're to support that, the size of pgsize_bitmap
> will need to change as well.
>=20
[Sethi Varun-B16395] Correct, this needs to be fixed. I will try to address=
this
In a separate patch (would require changes to iommu_map).
> > > +static int map_liodn(int liodn, struct fsl_dma_domain *dma_domain)
> > > +{
> > > + u32 subwin_cnt =3D dma_domain->subwin_cnt;
> > > + unsigned long rpn;
> > > + int ret =3D 0, i;
> > > +
> > > + if (subwin_cnt) {
> > > + struct dma_subwindow *sub_win_ptr =3D
> > > + &dma_domain->sub_win_arr[0];
> > > + for (i =3D 0; i < subwin_cnt; i++) {
> > > + if (sub_win_ptr[i].valid) {
> > > + rpn =3D sub_win_ptr[i].paddr >>
> > > + PAMU_PAGE_SHIFT,
> > > + spin_lock(&iommu_lock);
> > > + ret =3D pamu_config_spaace(liodn,
> > subwin_cnt, i,
> > > +
> > sub_win_ptr[i].size,
> > > + -1,
> > > + rpn,
> > > +
> > dma_domain->snoop_id,
> > > +
> > dma_domain->stash_id,
> > > + (i > 0) ?
> > 1 : 0,
> > > +
> > sub_win_ptr[i].prot);
> > > + spin_unlock(&iommu_lock);
> > > + if (ret) {
> > > + pr_err("PAMU SPAACE
> > configuration failed for liodn %d\n",
> > > + liodn);
> > > + return ret;
> > > + }
> > > + }
> > > + }
>=20
> Break up that nesting with some subfunctions.
>=20
> > > + while (!list_empty(&dma_domain->devices)) {
> > > + info =3D list_entry(dma_domain->devices.next,
> > > + struct device_domain_info, link);
> > > + remove_domain_ref(info, dma_domain->subwin_cnt);
> > > + }
> >
> > I wonder if you should use list_for_each_safe() instead.
>=20
> The above is simpler if you're destroying the entire list.
>=20
> > > +}
> > > +
> > > +static int configure_domain_dma_state(struct fsl_dma_domain
> > *dma_domain, int enable)
> >
> > bool enable
> >
> > Finally, please CC: me on all IOMMU and PAMU patches you post
> > upstream.
>=20
> Me too.
[Sethi Varun-B16395] Sure.
-Varun
^ permalink raw reply
* Re: [v2][PATCH 1/2] powerpc/kgdb: Fix a single stgep case of lazy IRQ
From: tiejun.chen @ 2012-10-24 1:17 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, jason.wessel
In-Reply-To: <1350528455-4751-1-git-send-email-tiejun.chen@windriver.com>
Please ignore v2 temporarily since I have to correct something lately.
Sorry for any inconvenience.
Tiejun
On 10/18/2012 10:47 AM, Tiejun Chen wrote:
> When we're in kgdb_singlestep(), we have to work around to get
> thread_info by copying from the kernel stack before calling
> kgdb_handle_exception(), then copying it back afterwards.
>
> But for PPC64, we have a lazy interrupt implementation. So after
> copying thread info frome kernle stack, if we need to replay an
> interrupt, we shouldn't restore that previous backup thread info
> to make sure we can replay an interrupt lately with a proper
> thread info.
>
> This patch use __check_irq_replay() to guarantee this process.
>
> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
> ---
> arch/powerpc/kernel/irq.c | 12 +++++++++++-
> arch/powerpc/kernel/kgdb.c | 7 ++++---
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index 71413f4..a773789 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -332,7 +332,17 @@ bool prep_irq_for_idle(void)
> return true;
> }
>
> -#endif /* CONFIG_PPC64 */
> +notrace unsigned int check_irq_replay(void)
> +{
> + return __check_irq_replay();
> +}
> +#else /* CONFIG_PPC64 */
> +notrace unsigned int check_irq_replay(void)
> +{
> + return 0;
> +}
> +#endif /* !CONFIG_PPC64 */
> +EXPORT_SYMBOL(check_irq_replay);
>
> int arch_show_interrupts(struct seq_file *p, int prec)
> {
> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c
> index c470a40..c4af341 100644
> --- a/arch/powerpc/kernel/kgdb.c
> +++ b/arch/powerpc/kernel/kgdb.c
> @@ -151,6 +151,7 @@ static int kgdb_handle_breakpoint(struct pt_regs *regs)
> return 1;
> }
>
> +extern notrace unsigned int check_irq_replay(void);
> static int kgdb_singlestep(struct pt_regs *regs)
> {
> struct thread_info *thread_info, *exception_thread_info;
> @@ -181,9 +182,9 @@ static int kgdb_singlestep(struct pt_regs *regs)
>
> kgdb_handle_exception(0, SIGTRAP, 0, regs);
>
> - if (thread_info != exception_thread_info)
> - /* Restore current_thread_info lastly. */
> - memcpy(exception_thread_info, backup_current_thread_info, sizeof *thread_info);
> + if ((thread_info != exception_thread_info) && (!check_irq_replay()))
> + /* Restore current_thread_info lastly only if we don't replay interrupt. */
> + memcpy(exception_thread_info, backup_current_thread_info, sizeof *thread_info);
>
> return 1;
> }
>
^ permalink raw reply
* RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM support
From: Jia Hongtao-B38951 @ 2012-10-24 1:58 UTC (permalink / raw)
To: Jia Hongtao-B38951, Kumar Gala
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <30C76F52-4022-459D-8B84-876B1A572ABE@kernel.crashing.org>
Hi Kumar,
This PCI controller PM thing is pending for nearly a month without
further discussion. Maybe it's time now to reach an agreement.
- Hongtao.
> -----Original Message-----
> From: Jia Hongtao-B38951
> Sent: Friday, October 19, 2012 12:15 PM
> To: 'Kumar Gala'
> Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
> Subject: RE: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
> support
>=20
> > -----Original Message-----
> > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > Sent: Thursday, September 27, 2012 8:06 PM
> > To: Jia Hongtao-B38951
> > Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; Li Yang-R58472
> > Subject: Re: [PATCH][V4] powerpc/fsl-pci: Add pci inbound/outbound PM
> > support
> >
> > >>>>>>>>>>
> > >>>>>>>>>> On Sep 17, 2012, at 9:10 PM, Jia Hongtao wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Power supply for PCI inbound/outbound window registers is
> > >>>>>>>>>>> off when system go to deep-sleep state. We save the values
> > >>>>>>>>>>> of registers
> > >>>>>>> before
> > >>>>>>>>>>> suspend and restore to registers after resume.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Signed-off-by: Jiang Yutang <b14898@freescale.com>
> > >>>>>>>>>>> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> > >>>>>>>>>>> Signed-off-by: Li Yang <leoli@freescale.com>
> > >>>>>>>>>>> ---
> > >>>>>>>>>>> Changes for V4:
> > >>>>>>>>>>> We just rebase the patch upon following patch:
> > >>>>>>>>>>> powerpc/fsl-pci: Unify pci/pcie initialization code
> > >>>>>>>>>>>
> > >>>>>>>>>>> arch/powerpc/include/asm/pci-bridge.h | 2 +-
> > >>>>>>>>>>> arch/powerpc/sysdev/fsl_pci.c | 121
> > >>>>>>>>>> +++++++++++++++++++++++++++++++++
> > >>>>>>>>>>> 2 files changed, 122 insertions(+), 1 deletions(-)
> > >>>>>>>>>>
> > >>>>>>>>>> Did you ever compare this to just re-parsing device tree
> > method?
> > >>>>>>>>>>
> > >>>>>>>>>> - k
> > >>>>>>>>>
> > >>>>>>>>> I tested the re-parsing way by using setup_pci_atmu() when
> > >> resume.
> > >>>>>>>>> And I found out that re-parsing will *change* outbound IO
> > >>>>>>>>> translation address regitster.
> > >>>>>>>>>
> > >>>>>>>>> It seems that in the first bootup, after setup_atmu()
> > >>>>>>>>> pcibios_setup_phb_resources() may update hose->io_resource,
> > >>>>>>>>> but atmu is not updated according to the new
> > >>>>>>>>> hose->io_resource
> > value.
> > >>>>>>>>> In resume from sleep setup_atmu() will reset atmu according
> > >>>>>>>>> to the new hose->io_resource value. So the setup_atmu() will
> > >>>>>>>>> cause different result on outbound IO register between first
> > >>>>>>>>> bootup and resume from sleep.
> > >>>>>>>>>
> > >>>>>>>>> So... There's a possibility that in the first bootup atmu is
> > >>>>>>>>> not setup properly.
> > >>>>>>>>
> > >>>>>>>> [Are you seeing this happen in your testing? If so its a bug
> > >>>>>>>> we need
> > >>>>>>> to look at fixing.]
> > >>>>>>>>
> > >>>>>>>> Yes, I see this in my testing.
> > >>>>>>>> Also PCIe ethernet card works well after resuming from sleep
> > >>>>>>>> in both
> > >>>>>>> save/restore
> > >>>>>>>> and re-parsing way. (Maybe PCIe ethernet card don't need
> > >>>>>>>> outbound IO
> > >>>>>>> resource)
> > >>>>>>>> So, I guess the result of re-parsing (actually it's re-setup)
> > >>>>>>>> is right
> > >>>>>>> and ATMU is not setup
> > >>>>>>>> properly at the first bootup.
> > >>>>>>>
> > >>>>>>> Are you seeing the following message - "PCI: I/O resource not
> > >>>>>>> set for host bridge" ?
> > >>>>>>
> > >>>>>> No.
> > >>>>>>
> > >>>>>>>
> > >>>>>>> Trying to understand why you'd hit the reassignment of
> > io_resource.
> > >>>>>>>
> > >>>>>>> - k
> > >>>>>>>
> > >>>>>>
> > >>>>>> I did some investigations and the conclusion is:
> > >>>>>>
> > >>>>>> io_resource.flags & IORESOURCE_IO are both positive but
> > >>>>>> io_resource.start is 0 before pcibios_setup_phb_io_space() is
> done.
> > >>>>>>
> > >>>>>> The sequence of related process listed below:
> > >>>>>> fsl_add_bridge() -> setup_pci_atmu()
> > >>>>>> pcibios_init() -> pcibios_scan_phb() ->
> > >>>>>> pcibios_setup_phb_io_space()
> > >>>>>>
> > >>>>>> Because fsl_add_bridge() must be finished before pcibios_init()
> > >>>>>> so ATMU is set when io_resource.start is 0. That means outbound
> > >>>>>> IO regs are not set.
> > >>>>>>
> > >>>>>> If system re-setup ATMU the io_resource.start has already
> > >>>>>> updated so outbound IO regs are set.
> > >>>>>>
> > >>>>>> My question is:
> > >>>>>> Is there any problem if outbound IO regs are not set in first
> > >> bootup?
> > >>>
> > >>> Yes, it means that IO transactions would not work.
> > >>
> > >> I agree.
> > >>
> > >>>
> > >>>>> Please also provide the IO resource address range before and
> > >>>>> after the pci scan. Then we can evaluate if the range is needed
> > >>>>> to be mapped
> > >>> via
> > >>>>> ATMU.
> > >>>>>
> > >>>>> Leo
> > >>>>
> > >>>> Since potar is set by out_be32(&pci->pow[j].potar, (hose-
> > >>>> io_resource.start >> 12); I provide the result of
> > >>>> hose->io_resource.start >> 12 as follows:
> > >>>>
> > >>>> pcie@ffe09000:
> > >>>> before pci scan: io_resource.start >> 12: 0 after pci scan :
> > >>>> io_resource.start >> 12: ff7ed
> > >>>>
> > >>>> pcie@ffe0a000:
> > >>>> before pci scan: io_resource.start >> 12: 0 after pci scan :
> > >>>> io_resource.start >> 12: ff7db
> > >>>>
> > >>>> pcie@ffe0b000:
> > >>>> before pci scan: io_resource.start >> 12: 0 after pci scan :
> > >>>> io_resource.start >> 12: ff7c9
> > >>>>
> > >>>> Note that I tested on P1022DS.
> > >>>>
> > >>>> - Hongtao.
> > >>>
> > >>> 1. What's the device tree nodes for PCIe look like?
> > >>> 2. Can you get the pr_debug() in setup_pci_atmu() to print and
> > >>> report results (as well as full boot log)
> > >>
> > >> Please refer to the attached file.
> > >> In the log file I also print the device tree.
> > >>
> > >> - Hongtao.
> > >>
> > >>>
> > >>> However, I think the change of the io_resource.start is normal and
> > >>> correct behavior.
> > >>>
> > >>> - k
> > >>>
> > >>
> > >
> > > Hi Kumar,
> > > I have already sent the log.
> > > Do you have any comment on it?
> > >
> > > Thanks.
> > > - Hongtao.
> > >
> >
> > Hongtao,
> >
> > You mentioned:
> >
> > > I tested the re-parsing way by using setup_pci_atmu() when resume.
> > > And I found out that re-parsing will *change* outbound IO
> > > translation address regitster.
> >
> > What do the values look like in both ATMU registers and io_resource if
> > you reparse?
> >
> > - k
>=20
>=20
> Hi Kumar,
>=20
> About this topic do you have any further comments?
>=20
> Thanks.
> - Hongtao.
^ permalink raw reply
* Re: ELDK 4.2/kilauea/3.5+ kernel broken
From: Robert Berger @ 2012-10-24 5:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, rsarmah, mla
In-Reply-To: <1350849666.2476.138.camel__11705.9888471433$1350849778$gmane$org@pasglop>
Hi Ben,
>
> Remind me what is the symptom ? A specific device isn't working ? Or the
> whole kernel goes toast ?
The whole kernel goes toast! Just reboots without saying much before;)
> My feeling is that those patches make MSIs
> work (well that's what they are supposed to do) and for some reason that
> doesn't agree with whatever you have connected to the PCIe slot...
I have nothing connected to the PCIe slot. Just a standard kilauea eval
board with a defconfig and a 3.6 kernel, so if someone has a kilauea
board it should be very easy to reproduce.
Mai, Rupjyoti do you have a kilauea bard lying around to test?
Maybe it's the kilauea fdt?
If I hard code NR_MSI_IRQS (as it used to be) at least the kernel boots
and I can work with the board. (I don't think MSI interrupts work).
23c23
< #define DEBUG
---
>
47d46
< #define NR_MSI_IRQS 4
55c54
< int msi_virqs[NR_MSI_IRQS];
---
> int *msi_virqs;
67c66
< err = msi_bitmap_alloc(&msi_data->bitmap, NR_MSI_IRQS,
---
> err = msi_bitmap_alloc(&msi_data->bitmap, msi_irqs,
88a88,92
> msi_data->msi_virqs = kmalloc((msi_irqs) * sizeof(int),
> GFP_KERNEL);
> if (!msi_data->msi_virqs)
> return -ENOMEM;
>
192a197,198
> dma_free_coherent(&dev->dev, 64, msi_virt, msi_phys);
>
202c208
< for (i = 0; i < NR_MSI_IRQS; i++) {
---
> for (i = 0; i < msi_irqs; i++) {
223,224d228
< /*msi = &ppc4xx_msi;*//*keep the msi data for further use*/
<
Regards,
Robert
>
> Cheers,
> Ben.
>
...If it's there, and you can see it, it's real. - If it's not there,
and you can see it, it's virtual.- If it's there, and you can't see it,
it's transparent.- If it's not there, and you can't see it, you erased
it. (from some mailing list)
My public pgp key is available,at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
^ permalink raw reply
* Re: [m68k,powerpc,dma,ethernet,freescale RFA] Coldfire m54xx FEC ethernet driver
From: Greg Ungerer @ 2012-10-24 6:30 UTC (permalink / raw)
To: Philippe De Muyter
Cc: uClinux development list, netdev, linux-kernel, linux-m68k,
stany.marcel, linuxppc-dev
In-Reply-To: <20121016080349.GA8427@frolo.macqel>
Hi Philippe,
On 16/10/12 18:03, Philippe De Muyter wrote:
> On Tue, Oct 16, 2012 at 04:39:05PM +1000, Greg Ungerer wrote:
>> On 09/10/12 19:07, Philippe De Muyter wrote:
>>> [CCing lkml, linux-ppc, netdev, linux-m68k]
>>>
>>> Hello kernel sources architects
>>>
>>> I have a working driver for the m54xx FEC ethernet driver that I
>>> would like to integrate in the kernel tree. Problems are that
>>> - this driver needs an associated DMA driver (provided by FreeScale)
>>> wich is not dma-engine enabled
>>> - they're are already many fec drivers in the kernel tree, and
>>> at least one, fec_mpc52xx.c, seems to be very similar (information
>>> below), to the one for the mcf54xx, except it uses a differently
>>> named associated DMA driver (BestComm/SmartDma/SDMA) which is also
>>> not dma-engine enabled, and even kept hidden in /arch/powerpc where
>>> it is inaccessible when compiling for m68k. The underlying DMA part
>>> from Freescale however seems similar to the one used in the
>>> m54xx. (again, see information below)
>>>
>>> So, now I am lost, what should I do ?
>>>
>>> The current state of my patches
>>> [http://mailman.uclinux.org/pipermail/uclinux-dev/2012-September/052147.html]
>>> is pushing the freescale provided MCD_DMA dma driver to /drivers/dma,
>>> without adding the dma-engine compatibility layer, and adding the specific
>>> fec_m54xx ethernet driver to /drivers/net/ethernet/freescale
>>
>> Do you get any responses?
>> I didn't see any...
>
> No, and none also about my simpler patch moving arch/powerpc/sysdev/bestcomm
> to drivers/dma/bestcomm (except a private and useful one telling me how to
> set '-M' option as default for 'git format-patch'), but at least this simpler
> patch seems to be in a wait bucket at
> http://patchwork.ozlabs.org/project/linuxppc-dev/list/.
Well, something useful then :-)
Feel free to send me the m68k header file updates as a patch (or patches
as appropriate), lets get those in now. They are worthwhile changes
on their own.
In light of no other other feedback you may want to push ahead then
with your patches to put the DMA engine code in drivers/dma. That
does seem like the right place to put it.
The new fec driver code should go to the netdev list for review.
Regards
Greg
> Regards
>
> Philippe
>
> PS: -M as default for 'git format-patch':
>
> put
> [diff]
> renames = true
> in .git/config
>
>>
>> Regards
>> Greg
>>
>>
>>
>>> On Tue, Oct 09, 2012 at 04:12:44PM +1000, Greg Ungerer wrote:
>>>> Hi Philippe,
>>>>
>>>> On 05/10/12 01:03, Philippe De Muyter wrote:
>>>>> On Thu, Oct 04, 2012 at 04:56:01PM +0200, Philippe De Muyter wrote:
>>>>>> On Thu, Oct 04, 2012 at 11:33:32PM +1000, Greg Ungerer wrote:
>>>>>>>
>>>>>>> My biggest concern is the amount of MCD/DMA support code. And it is
>>>>>>> all done quite differently to everything else in the kernel. We may
>>>>>>> get a bit of push back from kernel folk who look after DMA.
>>>>>>
>>>>>> Actually, there is already a similar code in
>>>>>> arch/powerpc/sysdev/bestcomm
>>>>>> (also from freescale, maybe an identical part, but I did not find any
>>>>>> usable doc), but the powerpc folks kept that hidden in the arch/powerpc
>>>>>> tree, instead of installing it in drivers/dma.
>>>>>
>>>>> The MCD DMA or DMA FEC code from freescale has a comment implying that
>>>>> this
>>>>> was first used in the MPC8220 part. And Montavista has a MPC8220 port,
>>>>> but
>>>>> I did not find it, so I do not know where they installed the MCD DMA
>>>>> driver.
>>>>
>>>> Ok, looks like there is a bit a variance in all this.
>>>
>>> I also began to read the mpc5200 user's guide parts about the fec and
>>> BestComm/SmartDma/SDMA (not sure which one is the official FreeScale name)
>>> and they look very similar, but not identical, to their m54xx
>>> counterparts.
>>>
>>> It seems possible to make the fec_mpc52xx.c driver work for the m54xx
>>> but that needs at least:
>>> - moving some files or part of them from /arch/powerpc/sysdev and
>>> /arch/powerpc/include/asm to /drivers/dma and /include/linux,
>>> - renaming the fec_mpc52xx files to a more sensible name,
>>> - providing out_be32 and in_be32 in /arch/m68k/include/asm/io.h,
>>> - and then unifying the interface to BestComm/SmartDma/SDMA and MCD_DMA
>>> in mcf_52xx.c.
>>>
>>> An additional problem is that the freescale docs for powerpcs and for
>>> coldfires do not use the same mnemonics for the same registers.
>>>
>>> e.g. FEC registers
>>> offset MPC5200 MCF5484
>>> ====== ======= =======
>>> 000 FEC_ID n/a
>>> 004 IEVENT EIR
>>> 008 IMASK EIMR
>>> 010 R_DES_ACTIVE n/a
>>> 014 X_DES_ACTIVE n/a
>>> 024 ECNTRL ECR
>>> 040 MII_DATA MDATA
>>> 044 MII_SPEED MSCR
>>> 064 MIB_CONTROL MIBC
>>> 084 R_CNTRL RCR
>>> 088 R_HASH RHR
>>> 0C4 X_CNTRL TCR
>>> 0E4 PADDR1 PALR
>>> 0E8 PADDR2 PAHR
>>> 0EC OP_PAUSE OPD
>>> 118 IADDR1 IAUR
>>> 11C IADDR1 IALR
>>> 120 GADDR1 GAUR
>>> 124 GADDR2 GALR
>>> 144 X_WMRK FECTFWR
>>> 184 RFIFO_DATA FECRFDR
>>> 188 RFIFO_STATUS FECRFSR
>>> 18C RFIFO_CONTROL FECRFCR
>>> 190 RFIFO_LRF_PTR FECRLRFP
>>> 194 RFIFO_LWF_PTR FECRLWFP
>>> 198 RFIFO_ALARM FECRFAR
>>> 19C RFIFO_RDPTR FECRFRP
>>> 1A0 RFIFO_WRPTR FECRFWP
>>> 1A4 TFIFO_DATA FECTFDR
>>> 1A8 TFIFO_STATUS FECTFSR
>>> 1AC TFIFO_CONTROL FECTFCR
>>> 1B0 TFIFO_LRF_PTR FECTLRFP
>>> 1B4 TFIFO_LWF_PTR FECTLWFP
>>> 1B8 TFIFO_ALARM FECTFAR
>>> 1BC TFIFO_RDPTR FECTFRP
>>> 1C0 TFIFO_WRPTR FECTFWP
>>> 1C4 RESET_CNTRL FECFRST
>>> 1C8 XMIT_FSM FECCTCWR
>>>
>>>> Probably the best thing to do is post the patches on the linux kernel
>>>> mailing list then, asking for direction on a dma driver.
>>>>
>>>> I have no problem with it going into the arch/m68k area. So that is
>>>> always an option.
>>>
>>> For the dma engines, the similarity is also obvious. For example, find
>>> below side by side mpc52xx and m54xx definitions for the
>>> main DMA registers :
>>>
>>> from mpc52xx.h from MCD_dma.h
>>> /* SDMA */ /* MCD_DMA */
>>> struct mpc52xx_sdma { struct dmaRegs {
>>> u32 taskBar; /* 0x00 */ u32 taskbar;
>>> u32 currentPointer; /* 0x04 */ u32 currPtr;
>>> u32 endPointer; /* 0x08 */ u32 endPtr;
>>> u32 variablePointer; /* 0x0c */ u32 varTablePtr;
>>>
>>> u8 IntVect1; /* 0x10 */ u16 dma_rsvd0;
>>> u8 IntVect2; /* 0x11 */
>>> u16 PtdCntrl; /* 0x12 */ u16 ptdControl;
>>>
>>> u32 IntPend; /* 0x14 */ u32 intPending;
>>> u32 IntMask; /* 0x18 */ u32 intMask;
>>>
>>> u16 tcr[16]; /* 0x1c .. 0x3a */ u16 taskControl[16];
>>>
>>> u8 ipr[32]; /* 0x3c .. 0x5b */ u8 priority[32];
>>>
>>> u32 cReqSelect; /* 0x5c */ u32 initiatorMux;
>>> u32 task_size0; /* 0x60 */ u32 taskSize0;
>>> u32 task_size1; /* 0x64 */ u32 taskSize1;
>>> u32 MDEDebug; /* 0x68 */ u32 dma_rsvd1;
>>> u32 ADSDebug; /* 0x6c */ u32 dma_rsvd2;
>>> u32 Value1; /* 0x70 */ u32 debugComp1;
>>> u32 Value2; /* 0x74 */ u32 debugComp2;
>>> u32 Control; /* 0x78 */ u32 debugControl;
>>> u32 Status; /* 0x7c */ u32 debugStatus;
>>> u32 PTDDebug; /* 0x80 */ u32 ptdDebug;
>>> }; };
>
>
>
>
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [RFC][PATCH] perf: Add a few generic stalled-cycles events
From: Peter Zijlstra @ 2012-10-24 12:27 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: Robert Richter, Anton Blanchard, linux-kernel, eranian, acme,
linuxppc-dev, paulus, mpjohn, mingo, asharma
In-Reply-To: <20121016183148.GA25482@us.ibm.com>
On Tue, 2012-10-16 at 11:31 -0700, Sukadev Bhattiprolu wrote:
> On a side note, how does the kernel on x86 use the 'config' information i=
n=20
> say /sys/bus/event_source/devices/cpu/format/cccr ? On Power7, the raw
> code encodes the information such as the PMC to use for the event. Is tha=
t
> how the 'config' info in Intel is used ?
>=20
> Does the 'config' info change from system to system or is it static for
> a given event on a given CPU ?=20
Have a look at commits (tip/master):
641cc938815dfd09f8fa1ec72deb814f0938ac33
a47473939db20e3961b200eb00acf5fcf084d755
43c032febde48aabcf6d59f47cdcb7b5debbdc63
So basically
/sys/bus/event_source/devices/cpu/format/event
contains something like:
config:0-7
Which says that for the 'cpu' PMU, field 'event' fills
perf_event_attr::config bits 0 through 7 (for type=3DPERF_TYPE_RAW).
The perf tool syntax for this is:
perf stat -e 'cpu/event=3D0x3c/'
This basically allows you to expose bitfields in the 'raw' event format
for ease of writing raw events. I do not know if the Power PMU has such
or not.
Using this,
/sys/bus/event_source/devices/cpu/events/cpu-cycles
would contain something like:
event=3D0x3c
which one can use as:
perf stat -e 'cpu/event=3Dcpu-cycles/'
perf stat -e 'cpu/cpu-cycles/'
The tool will then read the sysfs file, substitute the content to
obtain:
perf stat -e 'cpu/event=3D0x3c/'
and run with that.
Within all this, the perf_event_attr::config* field names are hard-coded
special, so 'cpu/config=3D0xffff/' will always work, even without sysfs
format/ specification and is equivalent to the raw event stuff we had
before.
If the Power PMU lacks any structure to the raw config, you could simply
provide sysfs event/ files with:
config=3D0xdeadbeef
like content.
^ permalink raw reply
* Re: [PATCH] powerpc/usb: fix build warning
From: Sebastian Andrzej Siewior @ 2012-10-24 14:01 UTC (permalink / raw)
To: Kim Phillips; +Cc: linux-usb, linuxppc-dev, Shengzhou Liu
In-Reply-To: <20121008164731.75483b961a01e824731c552b@freescale.com>
> index 9bfde82..968f751 100644
> --- a/drivers/usb/host/ehci-fsl.c
> +++ b/drivers/usb/host/ehci-fsl.c
> @@ -222,7 +222,7 @@ static int ehci_fsl_setup_phy(struct usb_hcd *hcd,
>
> if (pdata->controller_ver < 0) {
> dev_warn(hcd->self.controller, "Could not get controller version\n");
> - return;
> + return -EINVAL;
> }
>
> portsc = ehci_readl(ehci, &ehci->regs->port_status[port_offset]);
Another patch (USB: ehci-fsl: Return valid error in ehci_fsl_setup_phy)
by-passed Greg and went via Linus into tree and is available in v3.7-rc2.
Sebastian
^ permalink raw reply
* Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
From: Laurent Pinchart @ 2012-10-25 0:33 UTC (permalink / raw)
To: Simon Haggett
Cc: Li Yang-R58472, Greg Kroah-Hartman, linux-usb@vger.kernel.org,
linux-kernel@vger.kernel.org, balbi@ti.com,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <508532DF.7050809@realvnc.com>
Hi Simon,
On Monday 22 October 2012 12:49:51 Simon Haggett wrote:
> On 22/10/12 11:47, Laurent Pinchart wrote:
> > On Monday 22 October 2012 03:33:19 Li Yang-R58472 wrote:
> >> On Saturday, October 20, 2012 1:37 AM Felipe Balbi wrote:
> >>> On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote:
> >>>> Some gadget drivers may attempt to dequeue requests for an endpoint
> >>>> that has already been disabled. For example, in the UVC gadget driver,
> >>>> uvc_function_set_alt() will call usb_ep_disable() when alt setting 0
> >>>> is selected. When the userspace application subsequently issues the
> >>>> VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes usb_ep_dequeue() to
> >>>
> >>> ensure that all requests have been cancelled.
> >>>
> >>> bug is on uvc gadget, then. Laurent ?
> >
> > We've discussed this topic a couple of months before. I believe that's not
> > a bug.
> >
> > http://68.183.106.108/lists/linux-usb/msg68869.html
> >
> >>> Also, fsl should be removed from the tree, I'm trying to persuade iMX
> >>> folks to use drivers/usb/chipidea instead.
> >>
> >> Besides the iMX usage, the driver is also being used by many Freescale
> >> PowerPC/Coldfire SoCs. I agree that it's ideal to move to a common
> >> driver.
> >> But it is a large task to make the chipidea driver works for all the
> >> hardware that fsl_udc had supported and been tested on.
> >>
> >>>> For the Freescale High Speed Dual-Role USB controller,
> >>>> fsl_ep_dequeue() provides the implementation of usb_ep_dequeue(). If
> >>>> this is called for a disabled endpoint, a kernel oops will occur when
> >>>
> >>> the ep->ep.desc field is dereferenced (by ep_index()).
> >>>
> >>>> fsl_ep_disable() sets this field to NULL, as well as deleting all
> >>>> pending requests for the endpoint.
> >>>>
> >>>> This patch adds an additional check to fsl_ep_dequeue() to ensure that
> >>>> the endpoint has not already been disabled before attempting to dequeue
> >>>
> >>> requests.
> >>>
> >>>> Signed-off-by: Simon Haggett <simon.haggett@realvnc.com>
> >>>> ---
> >>>>
> >>>> drivers/usb/gadget/fsl_udc_core.c | 5 ++++-
> >>>> 1 files changed, 4 insertions(+), 1 deletions(-)
> >>>>
> >>>> diff --git a/drivers/usb/gadget/fsl_udc_core.c
> >>>> b/drivers/usb/gadget/fsl_udc_core.c
> >>>> index 6ae70cb..acd513b 100644
> >>>> --- a/drivers/usb/gadget/fsl_udc_core.c
> >>>> +++ b/drivers/usb/gadget/fsl_udc_core.c
> >>>> @@ -955,7 +955,10 @@ static int fsl_ep_dequeue(struct usb_ep *_ep,
> >>>
> >>> struct usb_request *_req)
> >>>
> >>>> int ep_num, stopped, ret = 0;
> >>>> u32 epctrl;
> >>>>
> >>>> - if (!_ep || !_req)
> >>>> + /* Ensure that the ep and request are valid, and the ep is not
> >>>> + * disabled
> >>>> + */
> >>>> + if (!_ep || !_req || !ep->ep.desc)
> >>>>
> >>>> return -EINVAL;
> >
> > Shouldn't that last check be done with a lock taken ?
>
> I had presumed a lock wasn't necessary because ep->ep.desc is only set
> to NULL by fsl_ep_disable() which, since it is called by
> usb_ep_disable(), should only be invoked when no other task is using the
> endpoint (according to include/linux/usb/gadget.h). Furthermore, the
> chipidea UDC driver does check the equivalent of this field is not NULL
> without taking a lock (ep_dequeue() in drivers/usb/chipidea/udc.c).
>
> However, it is possible that I'm misunderstanding something here, so
> apologies if I am.
I might be wrong as well :-) I just wanted to point out something that
appeared to me as a possible issue.
> >>>> spin_lock_irqsave(&ep->udc->lock, flags);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/1] usb: gadget: Don't attempt to dequeue requests for a disabled USB endpoint on Freescale hardware
From: Laurent Pinchart @ 2012-10-25 0:36 UTC (permalink / raw)
To: balbi
Cc: Simon Haggett, Li Yang-R58472, Greg Kroah-Hartman,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20121022105601.GS14033@arwen.pp.htv.fi>
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]
Hi Felipe,
On Monday 22 October 2012 13:56:01 Felipe Balbi wrote:
> On Mon, Oct 22, 2012 at 12:47:21PM +0200, Laurent Pinchart wrote:
> > On Monday 22 October 2012 03:33:19 Li Yang-R58472 wrote:
> > > On Saturday, October 20, 2012 1:37 AM Felipe Balbi wrote:
> > > > On Fri, Oct 19, 2012 at 06:19:26PM +0100, Simon Haggett wrote:
> > > > > Some gadget drivers may attempt to dequeue requests for an endpoint
> > > > > that has already been disabled. For example, in the UVC gadget
> > > > > driver, uvc_function_set_alt() will call usb_ep_disable() when alt
> > > > > setting 0 is selected. When the userspace application subsequently
> > > > > issues the VIDIOC_STREAMOFF ioctl, uvc_video_enable() invokes
> > > > > usb_ep_dequeue() to ensure that all requests have been cancelled.
> > > >
> > > > bug is on uvc gadget, then. Laurent ?
> >
> > We've discussed this topic a couple of months before. I believe that's not
> > a bug.
> >
> > http://68.183.106.108/lists/linux-usb/msg68869.html
>
> fair enough :-)
>
> That's a different case, however. At the link above we're discussing
> dequeueing a request which is already being dequeued. $SUBJECT is trying
> to fix dequeueing of a request for an endpoint which isn't even enabled.
You've got a point there :-) That's a different case indeed, I'm open to (at
least evaluating) a fix in the UVC gadget driver if you think that's better.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* iMac (PM61) quieter fan?
From: Jeremy Elgin @ 2012-10-25 3:13 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
I'm running Ubuntu 12.04 on my iMac G4 1GHz (PowerMac6,1) and I've been looking for any installable option to quiet the fan, nothing I've found mentions PowerMac6,1 and the modules installed don't even mention different PM models, just therm_windtunnel.ko & windfarm_core.ko - this first module won't load (No such device) and the second isn't used by anything (yet), do I need to install a .deb package that'll talk to this module?
I know this is not really about development but it's specific to PPC, ok? :-)
Oh, I also have a Dual 2.0 GHz G5 (PowerMac7,3) that I'm keen to get Ubuntu running on as a headless server and it'll need fan controls too. What I mean to say is, I'm keen to help out with these two pieces of hardware should you need testers for them specifically.
[-- Attachment #2: Type: text/html, Size: 1232 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Remove no longer used ppc_md.idle_loop()
From: Michael Ellerman @ 2012-10-25 3:21 UTC (permalink / raw)
To: linuxppc-dev
The last user of ppc_md.idle_loop() was removed when we dropped the
legacy iSeries code, in commit 8ee3e0d.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/machdep.h | 3 ---
arch/powerpc/kernel/idle.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index c423197..a338bc7 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -166,9 +166,6 @@ struct machdep_calls {
unsigned long size,
pgprot_t vma_prot);
- /* Idle loop for this platform, leave empty for default idle loop */
- void (*idle_loop)(void);
-
/*
* Function for waiting for work with reduced power in idle loop;
* called with interrupts disabled.
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 2099d9a..ea78761 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -55,9 +55,6 @@ __setup("powersave=off", powersave_off);
*/
void cpu_idle(void)
{
- if (ppc_md.idle_loop)
- ppc_md.idle_loop(); /* doesn't return */
-
set_thread_flag(TIF_POLLING_NRFLAG);
while (1) {
tick_nohz_idle_enter();
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] powerpc/book3e: support kgdb for kernel space
From: Tiejun Chen @ 2012-10-25 6:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1351147410-17452-1-git-send-email-tiejun.chen@windriver.com>
Currently we need to skip this for supporting KGDB.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/exceptions-64e.S | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 43b654a..c5564d4 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -566,11 +566,14 @@ kernel_dbg_exc:
rfdi
/* Normal debug exception */
+1:
+#ifndef CONFIG_KGDB
/* XXX We only handle coming from userspace for now since we can't
* quite save properly an interrupted kernel state yet
*/
-1: andi. r14,r11,MSR_PR; /* check for userspace again */
+ andi. r14,r11,MSR_PR; /* check for userspace again */
beq kernel_dbg_exc; /* if from kernel mode */
+#endif
/* Now we mash up things to make it look like we are coming on a
* normal exception
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] powerpc/book3e: load critical/machine/debug exception stack
From: Tiejun Chen @ 2012-10-25 6:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, jason.wessel
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.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
arch/powerpc/kernel/exceptions-64e.S | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
index 4684e33..43b654a 100644
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -36,6 +36,30 @@
*/
#define SPECIAL_EXC_FRAME_SIZE INT_FRAME_SIZE
+/* only on book3e */
+#define DBG_STACK_BASE dbgirq_ctx
+#define MC_STACK_BASE mcheckirq_ctx
+#define CRIT_STACK_BASE critirq_ctx
+
+#ifdef CONFIG_SMP
+#define BOOK3E_LOAD_EXC_LEVEL_STACK(level) \
+ std r14,PACA_EX##level+EX_R14(r13); \
+ mfspr r14,SPRN_PIR; \
+ slwi r14,r14,3; \
+ LOAD_REG_ADDR(r10, level##_STACK_BASE); \
+ add r10,r10,r14; \
+ ld r10,0(r10); \
+ addi r10,r10,THREAD_SIZE; \
+ std r10,PACA_DBG_STACK(r13); \
+ ld r14,PACA_EX##level+EX_R14(r13);
+#else
+#define BOOK3E_LOAD_EXC_LEVEL_STACK(level) \
+ LOAD_REG_ADDR(r10, level##_STACK_BASE); \
+ ld r10,0(r10); \
+ addi r10,r10,THREAD_SIZE; \
+ std r10,PACA_DBG_STACK(r13);
+#endif
+
/* Exception prolog code for all exceptions */
#define EXCEPTION_PROLOG(n, intnum, type, addition) \
mtspr SPRN_SPRG_##type##_SCRATCH,r13; /* get spare registers */ \
@@ -68,18 +92,21 @@
#define SPRN_GDBELL_SRR1 SPRN_GSRR1
#define CRIT_SET_KSTACK \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(CRIT); \
ld r1,PACA_CRIT_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
#define SPRN_CRIT_SRR0 SPRN_CSRR0
#define SPRN_CRIT_SRR1 SPRN_CSRR1
#define DBG_SET_KSTACK \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(DBG); \
ld r1,PACA_DBG_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
#define SPRN_DBG_SRR0 SPRN_DSRR0
#define SPRN_DBG_SRR1 SPRN_DSRR1
#define MC_SET_KSTACK \
+ BOOK3E_LOAD_EXC_LEVEL_STACK(MC); \
ld r1,PACA_MC_STACK(r13); \
subi r1,r1,SPECIAL_EXC_FRAME_SIZE;
#define SPRN_MC_SRR0 SPRN_MCSRR0
--
1.7.9.5
^ permalink raw reply related
* [PATCH 3/3] kgdb/kgdbts: support ppc64
From: Tiejun Chen @ 2012-10-25 6:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, linux-kernel, jason.wessel
In-Reply-To: <1351147410-17452-1-git-send-email-tiejun.chen@windriver.com>
We can't look up the address of the entry point of the function simply
via that function symbol for all architectures.
For PPC64 ABI, actually there is a function descriptors structure.
A function descriptor is a three doubleword data structure that contains
the following values:
* The first doubleword contains the address of the entry point of
the function.
* The second doubleword contains the TOC base address for
the function.
* The third doubleword contains the environment pointer for
languages such as Pascal and PL/1.
So we should call a wapperred dereference_function_descriptor() to get
the address of the entry point of the function.
Note this is also safe for other architecture after refer to
"include/asm-generic/sections.h" since:
dereference_function_descriptor(p) always is (p) if without arched definition.
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
---
drivers/misc/kgdbts.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/misc/kgdbts.c b/drivers/misc/kgdbts.c
index 3aa9a96..4799e1f 100644
--- a/drivers/misc/kgdbts.c
+++ b/drivers/misc/kgdbts.c
@@ -103,6 +103,7 @@
#include <linux/delay.h>
#include <linux/kthread.h>
#include <linux/module.h>
+#include <asm/sections.h>
#define v1printk(a...) do { \
if (verbose) \
@@ -222,6 +223,7 @@ static unsigned long lookup_addr(char *arg)
addr = (unsigned long)do_fork;
else if (!strcmp(arg, "hw_break_val"))
addr = (unsigned long)&hw_break_val;
+ addr = (unsigned long )dereference_function_descriptor((void *)addr);
return addr;
}
--
1.7.9.5
^ permalink raw reply related
* Re: PCI device not working
From: Davide @ 2012-10-25 8:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <750F6602-132E-449A-A852-43E739EA6D3E@kernel.crashing.org>
Hi Kumar,
On Fri, Oct 05, 2012 at 07:47:24AM -0500, Kumar Gala wrote:
>
> On Oct 5, 2012, at 3:54 AM, Davide Viti wrote:
>
> >> On Oct 4, 2012, at 7:24 AM, Davide Viti wrote:
> >>
> >>> Hi,
> >>> it turns out that if define CONFIG_PCI_NOSCAN in u-boot (as per [1]), the
> >>> device behind the second controller is detected by the Linux kernel.
> >>>
> >>> Would
> >>> you suggest any particular patch I should apply to fix this (I'm using kernel
> >>> 2.6.34)
> >>>
> >>> thanx alot in advance
> >>> Davide
> >>>
> >>> [1] http://permalink.gmane.org/gmane.linux.ports.ppc.embedded/20140
> >>
> >> My suggestion would be to try and dump all the controller registers between the case that works and doesn't and compare. There's some minor setting difference that I'm guessing is causing issues.
> >>
> >> - k
>
> When I said controller registers, I meant the FSL PCI controller and the CCSR registers not the PCI cfg register space
>
I've collected a complete dump of the registers in the working and not working cases
0x9000: 0x80000048 (not working) -> 0x8003007c (ok)
0x9004: 0x00000000 (not working) -> 0x08000000 (ok)
According to the p1020 manual, the register fall in the PCI Express controller 2 area,
in particular:
0x9000 PEX_CONFIG_ADDR—PCI Express configuration address register
0x9004 PEX_CONFIG_DATA—PCI Express configuration data register
does that ring any bell?
thank you in advance
Davide
^ permalink raw reply
* Re: iMac (PM61) quieter fan?
From: Benjamin Herrenschmidt @ 2012-10-25 8:46 UTC (permalink / raw)
To: Jeremy Elgin; +Cc: linuxppc-dev
In-Reply-To: <26F74A8F-8BCD-4E97-99F4-8DF14C2568D6@jeremyelgin.me>
On Thu, 2012-10-25 at 16:13 +1300, Jeremy Elgin wrote:
> I'm running Ubuntu 12.04 on my iMac G4 1GHz (PowerMac6,1) and I've
> been looking for any installable option to quiet the fan, nothing I've
> found mentions PowerMac6,1 and the modules installed don't even
> mention different PM models, just therm_windtunnel.ko &
> windfarm_core.ko - this first module won't load (No such device) and
> the second isn't used by anything (yet), do I need to install a .deb
> package that'll talk to this module?
>
> I know this is not really about development but it's specific to PPC,
> ok? :-)
I don't know much about the fan control on the iMac G4. You can try
sending me a dump of /proc/device-tree (a tarball), it might tell us
more about what's in there.
> Oh, I also have a Dual 2.0 GHz G5 (PowerMac7,3) that I'm keen to get
> Ubuntu running on as a headless server and it'll need fan controls
> too. What I mean to say is, I'm keen to help out with these two pieces
> of hardware should you need testers for them specifically.
This should be fully supported already.
Cheers,
Ben.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [PATCH] powerpc/esdhc: enable the card insert/remove interrupt
From: Huang Changming-R66093 @ 2012-10-25 10:05 UTC (permalink / raw)
To: Anton Vorontsov
Cc: linuxppc-dev@lists.ozlabs.org, Chris Ball,
linux-mmc@vger.kernel.org
In-Reply-To: <110EED8CC96DFC488B7E717A2027A27C1C68D9@039-SN1MPN1-003.039d.mgd.msft.net>
SGksIEFudG9uLg0KQ291bGQgeW91IGhhdmUgYW55IGNvbW1lbnQgYWJvdXQgaXQ/DQpJZiBub3Qs
IEkgd2lsbCByZXNlbmQgdGhpcyBwYXRjaCB3aXRoIHYyLg0KDQpCZXN0IFJlZ2FyZHMNCkplcnJ5
IEh1YW5nDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1t
bWMtb3duZXJAdmdlci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtbW1jLQ0KPiBvd25lckB2Z2Vy
Lmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBIdWFuZyBDaGFuZ21pbmctUjY2MDkzDQo+IFNlbnQ6
IFR1ZXNkYXksIE9jdG9iZXIgMjMsIDIwMTIgNDo0MCBQTQ0KPiBUbzogQW50b24gVm9yb250c292
DQo+IENjOiBsaW51eC1tbWNAdmdlci5rZXJuZWwub3JnOyBDaHJpcyBCYWxsOyBLdW1hciBHYWxh
OyBsaW51eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRD
SF0gcG93ZXJwYy9lc2RoYzogZW5hYmxlIHRoZSBjYXJkIGluc2VydC9yZW1vdmUNCj4gaW50ZXJy
dXB0DQo+IA0KPiBIaSwgQW50b24NCj4gRm9yIEZTTCBTT0NzLCB0aGUgaW50ZXJydXB0IG1vZGUg
aXMgc3VwcG9ydCBmb3IgY2FyZCBkZXRlY3QuDQo+IEZvciBzb21lIHJlYXNvbnMsIHNvbWUgYm9h
cmQgY2FuJ3Qgc3VwcG9ydCB0aGlzIGZlYXR1cmUsIHN1Y2ggYXMNCj4gbXBjODM3eG1kcyBib2Fy
ZCwgYnV0IG1wYzgzN3hyZGIgYm9hcmQgc3VwcG9ydCBpdC4NCj4gDQo+IEkgc2VlIHlvdXIgbGlu
a3MsIGl0IGlzIGFib3V0IHRoZSBETUEgKHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHAyMDIwIGRvbid0
DQo+IHN1cHBvcnQgRE1BLCBuZWVkIHRvIGVuYWJsZSB0aGUgUElPIG1vZGUsIGJ1dCB0aGUgbGF0
ZXIgdmVyc2lvbiBoYXMgZml4ZWQNCj4gdGhpcyBpc3N1ZSkuDQo+IA0KPiBCZXN0IFJlZ2FyZHMN
Cj4gSmVycnkgSHVhbmcNCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+
ID4gRnJvbTogbGludXgtbW1jLW93bmVyQHZnZXIua2VybmVsLm9yZyBbbWFpbHRvOmxpbnV4LW1t
Yy0NCj4gPiBvd25lckB2Z2VyLmtlcm5lbC5vcmddIE9uIEJlaGFsZiBPZiBBbnRvbiBWb3JvbnRz
b3YNCj4gPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIzLCAyMDEyIDQ6MjcgUE0NCj4gPiBUbzog
SHVhbmcgQ2hhbmdtaW5nLVI2NjA5Mw0KPiA+IENjOiBsaW51eC1tbWNAdmdlci5rZXJuZWwub3Jn
OyBIdWFuZyBDaGFuZ21pbmctUjY2MDkzOyBDaHJpcyBCYWxsOw0KPiA+IEt1bWFyIEdhbGE7IGxp
bnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnDQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSF0gcG93
ZXJwYy9lc2RoYzogZW5hYmxlIHRoZSBjYXJkIGluc2VydC9yZW1vdmUNCj4gPiBpbnRlcnJ1cHQN
Cj4gPg0KPiA+IE9uIFR1ZSwgT2N0IDIzLCAyMDEyIGF0IDAzOjAxOjE3UE0gKzA4MDAsIHI2NjA5
M0BmcmVlc2NhbGUuY29tIHdyb3RlOg0KPiA+ID4gRnJvbTogSmVycnkgSHVhbmcgPENoYW5nLU1p
bmcuSHVhbmdAZnJlZXNjYWxlLmNvbT4NCj4gPiA+DQo+ID4gPiBUaGUgY3VycmVudCBlU0RIQyBk
cml2ZXIgdXNlIHRoZSBwb2xsIG1vZGUgdG8gZGV0ZWN0IGlmIHRoZSBTRC9NTUMNCj4gPiA+IGNh
cmQgaXMgaW5zZXJ0ZWQgb3IgcmVtb3ZlZCwgd2hpY2ggd2lsbCBnZW5lcmF0ZSBtYW55IGludGVy
cnVwdHMgYW5kDQo+ID4gPiBpbXBhY3QgdGhlIHBlcmZvcm1hbmNlLg0KPiA+ID4gVGhlcmVmb3Jl
LCBjaGFuZ2UgdGhlIGRlZmF1bHQgY2FyZCBkZXRlY3QgdG8gaW50ZXJydXB0IG1vZGUsIGlmIHRo
ZQ0KPiA+ID4gYm9hcmQgY2FuJ3Qgc3VwcG9ydCB0aGlzIG1vZGUsIHdlIHN0aWxsIHVzZSB0aGUg
cG9sbCBtb2RlLg0KPiA+ID4NCj4gPiA+IFNpZ25lZC1vZmYtYnk6IEplcnJ5IEh1YW5nIDxDaGFu
Zy1NaW5nLkh1YW5nQGZyZWVzY2FsZS5jb20+DQo+ID4gPiBDQzogQW50b24gVm9yb250c292IDxj
Ym91YXRtYWlscnVAZ21haWwuY29tPg0KPiA+ID4gQ0M6IENocmlzIEJhbGwgPGNqYkBsYXB0b3Au
b3JnPg0KPiA+ID4gLS0tDQo+ID4NCj4gPiBJSVJDLCB0aGUgY2FyZCBkZXRlY3Rpb24gaXMgYnJv
a2VuIFNPQy1yZXZpc2lvbi13aXNlLCBub3QgYm9hcmQtd2lzZS4NCj4gPiBTbyB0aGUgY2hhbmdl
IHNlZW1zIHdyb25nLg0KPiA+DQo+ID4gQWxzbywgdGFrZSBhIGxvb2sgYXQgdGhpczoNCj4gPg0K
PiA+IAlodHRwOi8vbGttbC5vcmcvbGttbC8yMDEwLzcvMTQvMTI3DQo+ID4NCj4gPiBJIHN0YXJ0
ZWQgdGhlIHdvcmsgYnV0IG5ldmVyIGZpbmlzaGVkLCB1bmZvcnR1bmF0ZWx5IGl0IGNhdXNlZCBz
b21lDQo+ID4gcmVncmVzc2lvbnMgZm9yIG5vbi1GU0wgaGFyZHdhcmUuLi4NCj4gPg0KPiA+ID4g
IGRyaXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNkaGMuYyB8ICAgIDcgKysrKysrLQ0KPiA+ID4g
IDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkNCj4gPiA+DQo+
ID4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1vZi1lc2RoYy5jDQo+ID4g
PiBiL2RyaXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2YtZXNkaGMuYw0KPiA+ID4gaW5kZXggZmZjMTIy
Ni4uNWRjMzYyZiAxMDA2NDQNCj4gPiA+IC0tLSBhL2RyaXZlcnMvbW1jL2hvc3Qvc2RoY2ktb2Yt
ZXNkaGMuYw0KPiA+ID4gKysrIGIvZHJpdmVycy9tbWMvaG9zdC9zZGhjaS1vZi1lc2RoYy5jDQo+
ID4gPiBAQCAtMTk2LDYgKzE5NiwxMSBAQCBzdGF0aWMgdm9pZCBlc2RoY19vZl9kZXRlY3RfbGlt
aXRhdGlvbihzdHJ1Y3QNCj4gPiBwbGF0Zm9ybV9kZXZpY2UgKnBkZXYsDQo+ID4gPiAgCWlmICh2
dm4gPT0gVkVORE9SX1ZfMjIpDQo+ID4gPiAgCQlwZGF0YS0+cXVpcmtzMiB8PSBTREhDSV9RVUlS
SzJfSE9TVF9OT19DTUQyMzsNCj4gPiA+DQo+ID4gPiArCS8qIFA0MDgwRFMgYW5kIE1QQzgzN1hN
RFMgYm9hcmQgZG9uJ3Qgc3VwcG9ydCBpbnRlcnJ1cHQgbW9kZSAqLw0KPiA+ID4gKwlpZiAob2Zf
bWFjaGluZV9pc19jb21wYXRpYmxlKCJmc2wsbXBjODM3eG1kcyIpIHx8DQo+ID4gPiArCSAgICBv
Zl9tYWNoaW5lX2lzX2NvbXBhdGlibGUoImZzbCxQNDA4MERTIikpDQo+ID4gPiArCQlwZGF0YS0+
cXVpcmtzIHw9IFNESENJX1FVSVJLX0JST0tFTl9DQVJEX0RFVEVDVElPTjsNCj4gPiA+ICsNCj4g
PiA+ICAJaW91bm1hcChpb2FkZHIpOw0KPiA+ID4gIGVuZDoNCj4gPiA+ICAJcmV0dXJuOw0KPiA+
ID4gQEAgLTIyMyw3ICsyMjgsNyBAQCBzdGF0aWMgc3RydWN0IHNkaGNpX3BsdGZtX2RhdGEgc2Ro
Y2lfZXNkaGNfcGRhdGENCj4gPiA+ID0NCj4gPiB7DQo+ID4gPiAgCSAqIGNhcmQgZGV0ZWN0aW9u
IGNvdWxkIGJlIGhhbmRsZWQgdmlhIEdQSU8NCj4gPiA+ICAJICogZVNESEMgY2Fubm90IHN1cHBv
cnQgRW5kIEF0dHJpYnV0ZSBpbiBOT1AgQURNQSBkZXNjcmlwdG9yDQo+ID4gPiAgCSAqLw0KPiA+
ID4gLQkucXVpcmtzID0gRVNESENfREVGQVVMVF9RVUlSS1MgfCBTREhDSV9RVUlSS19CUk9LRU5f
Q0FSRF9ERVRFQ1RJT04NCj4gPiA+ICsJLnF1aXJrcyA9IEVTREhDX0RFRkFVTFRfUVVJUktTDQo+
ID4gPiAgCQl8IFNESENJX1FVSVJLX05PX0NBUkRfTk9fUkVTRVQNCj4gPiA+ICAJCXwgU0RIQ0lf
UVVJUktfTk9fRU5EQVRUUl9JTl9OT1BERVNDLA0KPiA+ID4gIAkub3BzID0gJnNkaGNpX2VzZGhj
X29wcywNCj4gPiA+IC0tDQo+ID4gPiAxLjcuOS41DQo+ID4gLS0NCj4gPiBUbyB1bnN1YnNjcmli
ZSBmcm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtbW1jIg0K
PiA+IGluIHRoZSBib2R5IG9mIGEgbWVzc2FnZSB0byBtYWpvcmRvbW9Admdlci5rZXJuZWwub3Jn
IE1vcmUgbWFqb3Jkb21vDQo+ID4gaW5mbyBhdCBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9y
ZG9tby1pbmZvLmh0bWwNCj4gDQo+IE4gICAgIHIgIHkgICBiIFggIMendiBeICneunsubiArICAg
IHsgIGciICBebiByICAgeiAaICBoICAgICYgIB4gRyAgIGgNCj4gAygg6ZqOIN2iaiIgIBogG20g
ICAgIHog3pYgICBmICAgaCAgIH4gbQ0K
^ permalink raw reply
* Re: [PATCH] powerpc/esdhc: enable the card insert/remove interrupt
From: Anton Vorontsov @ 2012-10-25 10:30 UTC (permalink / raw)
To: Huang Changming-R66093
Cc: linuxppc-dev@lists.ozlabs.org, Chris Ball,
linux-mmc@vger.kernel.org
In-Reply-To: <110EED8CC96DFC488B7E717A2027A27C1D7A42@039-SN1MPN1-003.039d.mgd.msft.net>
On Thu, Oct 25, 2012 at 10:05:44AM +0000, Huang Changming-R66093 wrote:
> Hi, Anton.
> Could you have any comment about it?
> If not, I will resend this patch with v2.
Technically, the patch looks fine.
But again, as far as I recall, the card detection logic was broken on the
SOC level (it's actually very hard to break it on the board level -- it
would either work or not, but in the eSDHC case it was just unreliable,
again, if I recall everything correctly -- I might be wrong).
Of course you know the hardware much better, so your words weight more, so
you don't need my ack on the patch. :)
Although there's a second issue: for P4080DS and mpc837x boards you still
have the same problem with polling method, right? It is causing
performance drops/freezes every like 100 ms, and that's why you want to
avoid the polling.
So, you've "fixed" some boards, but left others to suffer. Ideally, the
best fix would be to also make the card polling cheap.
Anyways, using (d) clause of the "Reviewer's statement of oversight", I
can easily give this:
Reviewed-by: Anton Vorontsov <cbouatmailru@gmail.com>
:)
Thanks!
[...]
> > > IIRC, the card detection is broken SOC-revision-wise, not board-wise.
> > > So the change seems wrong.
> > >
> > > Also, take a look at this:
> > >
> > > http://lkml.org/lkml/2010/7/14/127
> > >
> > > I started the work but never finished, unfortunately it caused some
> > > regressions for non-FSL hardware...
> > >
> > > > drivers/mmc/host/sdhci-of-esdhc.c | 7 ++++++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > index ffc1226..5dc362f 100644
> > > > --- a/drivers/mmc/host/sdhci-of-esdhc.c
> > > > +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> > > > @@ -196,6 +196,11 @@ static void esdhc_of_detect_limitation(struct
> > > platform_device *pdev,
> > > > if (vvn == VENDOR_V_22)
> > > > pdata->quirks2 |= SDHCI_QUIRK2_HOST_NO_CMD23;
> > > >
> > > > + /* P4080DS and MPC837XMDS board don't support interrupt mode */
> > > > + if (of_machine_is_compatible("fsl,mpc837xmds") ||
> > > > + of_machine_is_compatible("fsl,P4080DS"))
> > > > + pdata->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
> > > > +
> > > > iounmap(ioaddr);
> > > > end:
> > > > return;
> > > > @@ -223,7 +228,7 @@ static struct sdhci_pltfm_data sdhci_esdhc_pdata
> > > > =
> > > {
> > > > * card detection could be handled via GPIO
> > > > * eSDHC cannot support End Attribute in NOP ADMA descriptor
> > > > */
> > > > - .quirks = ESDHC_DEFAULT_QUIRKS | SDHCI_QUIRK_BROKEN_CARD_DETECTION
> > > > + .quirks = ESDHC_DEFAULT_QUIRKS
> > > > | SDHCI_QUIRK_NO_CARD_NO_RESET
> > > > | SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC,
> > > > .ops = &sdhci_esdhc_ops,
> > > > --
> > > > 1.7.9.5
^ permalink raw reply
* Re: PROBLEM: Linux 3.6.2 fails to boot on IBM Cell
From: Dennis Schridde @ 2012-10-25 19:33 UTC (permalink / raw)
To: Grant Likely; +Cc: Thomas Gleixner, linuxppc-dev
In-Reply-To: <6566742.NTPeeo2QHT@ernie>
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
Hello everyone!
Am Freitag, 19. Oktober 2012, 09:04:08 schrieb Dennis Schridde:
> Am Freitag, 19. Oktober 2012, 00:17:55 schrieb Grant Likely:
> > What does the boot log look like with the attached patch? (compiled
> > only, I haven't booted with it)
>
> Please find the log attached.
Have you found the cause or a fix for the problem?
Best regards,
Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Please pull 'merge' branch of 5xxx tree
From: Anatolij Gustschin @ 2012-10-25 20:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben,
please pull three mpc5200 fixes for 3.7:
Patch for pcm030 device tree fixing the probe() in pcm030-audio-fabric
driver. Changes to this driver have been merged in 3.7-rc1 via ASoC
tree, but this required device tree patch was submitted separately to
the linux-ppc list and is still missing in mainline. Without this patch
the probe() in pcm030-audio-fabric driver wrongly returns -ENODEV.
A patch from Wolfram fixing wrong invalid critical irq warnings for
all mpc5200 boards.
Another patch for all mpc5200 device trees fixing wrong L1 cell in
the LPB FIFO interrupt property and moving the LPB FIFO node to the
common mpc5200b.dtsi file so that this common node will be present
in all mpc5200 device trees.
All these patches have been in linux-next for a while.
Thanks,
Anatolij
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556:
Linux 3.7-rc2 (2012-10-20 12:11:32 -0700)
are available in the git repository at:
git://git.denx.de/linux-2.6-agust.git merge
Anatolij Gustschin (1):
powerpc/mpc5200: move lpbfifo node and fix its interrupt property
Eric Millbrandt (1):
powerpc/pcm030: add pcm030-audio-fabric to dts
Wolfram Sang (1):
powerpc: 52xx: nop out unsupported critical IRQs
arch/powerpc/boot/dts/mpc5200b.dtsi | 6 ++++++
arch/powerpc/boot/dts/o2d.dtsi | 6 ------
arch/powerpc/boot/dts/pcm030.dts | 7 ++++++-
arch/powerpc/platforms/52xx/mpc52xx_pic.c | 9 +++++----
4 files changed, 17 insertions(+), 11 deletions(-)
^ permalink raw reply
* Power Management issues in MPC8313 processor
From: Srivatsan Canchivaram @ 2012-10-25 22:07 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 7359 bytes --]
Hi,
I have a modem with a Freescale MPC8313E processor. I am trying to enable
power savings in the processor by placing it in Standby mode and resume
normal operation with a Wake-On-LAN magic packet.
Following the directions in the Freescale Power Management app note, I
enabled Power Management Support in the Linux kernel and device tree
configurations.
I ran the following command on the board:
echo standby > /sys/power/state
This caused the console to hang and there was no further response to
keyboard inputs. I enabled ‘no_console_suspend’ in the kernel and when I
loaded the new build and enabled standby mode, I observed an Oops trace:
RASCOM_QCU.7.0.0013 $ echo standby > /sys/power/state
<6>PM: Syncing fFreezing user space processes ... ilesystems ... <7>PM:
Entering standby sleep
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0x616d6570
Oops: Kernel access of bad area, sig: 11 [#1]
MPC831x RDB
Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon [last
unloaded: modem]
NIP: 616d6570 LR: c0165224 CTR: 616d6573
REGS: cd087d30 TRAP: 0400 Not tainted (2.6.27)
MSR: 20001032 <ME,IR,DR> CR: 28002024 XER: 20000000
TASK = cc312400[1196] 'echo' THREAD: cd086000
GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000
c06da4a0
GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000
100050b8
GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294
c0246180
GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c
cf821808
NIP [616d6570] 0x616d6570
LR [c0165224] platform_pm_suspend_noirq+0x84/0x88
Call Trace:
[cd087de0] [c0167e6c] pm_dev_dbg+0x70/0x18c (unreliable)
[cd087df0] [c0167cb4] pm_noirq_op+0x58/0xc8
[cd087e00] [c0168e08] device_power_down+0x78/0x1c4
[cd087e40] [c00471bc] suspend_devices_and_enter+0x1ec/0x258
[cd087e70] [c00473ac] enter_state+0x13c/0x198
[cd087e90] [c00474bc] state_store+0xb4/0xf8
[cd087eb0] [c013af68] kobj_attr_store+0x24/0x3c
[cd087ec0] [c00bf734] sysfs_write_file+0xe8/0x1e8
[cd087ef0] [c0078bbc] vfs_write+0xb4/0x16c
[cd087f10] [c0078d7c] sys_write+0x4c/0xa4
[cd087f40] [c000fa88] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0x4802679c
LR = 0x4803f0e8
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
---[ end trace b6a2457eea68b760 ]---
done.
<7>PM: Preparing system for standby sleep
<1>Freezing user space processes ... <7>PM: Entering standby sleep
<7>platform mpc83xx_wdt.0: preparing suspend
<7>fsl-gianfar fsl-gianfar.0: preparing suspend
<7>fsl-gianfar fsl-gianfar.1: preparing suspend
<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: preparing suspend
<7>serial8250 serial8250.0: preparing suspend
<7>serial8250 serial8250: preparing suspend
<7>platform Fixed MDIO bus.0: preparing suspend
<7>lm92 0-0049: legacy suspend
<7>lm92 0-0048: legacy suspend
<7>platform Fixed MDIO bus.0: suspend
<7>mdio_bus 24520:1f: legacy suspend
<7>Generic PHY 24520:01: legacy suspend
<7>Generic PHY 24520:00: legacy suspend
<7>serial8250 serial8250: suspend
<7>of_platform ee000600.timer: legacy suspend
<7>of_platform ee000500.timer: legacy suspend
<7>mpc83xx-pmc ee000b00.power: legacy suspend
<7>of_platform ee000700.pic: legacy suspend
<7>of_platform ee030000.crypto: legacy suspend
<7>of_platform ee004600.serial: legacy suspend
<7>of_platform ee004500.serial: legacy suspend
<7>of_platform ee025000.ethernet: legacy suspend
<7>of_platform ee024000.ethernet: legacy suspend
<7>of_platform ee024520.mdio: legacy suspend
<7>of_platform ee024e00.ptimer: legacy suspend
<7>of_platform ee0082a8.dma: legacy suspend
<7>mpc-i2c ee003100.i2c: legacy suspend
<7>mpc-i2c ee003000.i2c: legacy suspend
<7>of_platform ee000200.wdt: legacy suspend
<7>of_platform ee000000.soc8313: legacy suspend
<7>of-flash fc000000.flash: legacy suspend
<7>of_platform ee005000.localbus: legacy suspend
<7>serial8250 serial8250.0: suspend
<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: suspend
<7>fsl-gianfar fsl-gianfar.1: suspend
<7>fsl-gianfar fsl-gianfar.0: suspend
<7>platform mpc83xx_wdt.0: suspend
<6>PM: suspend devices took 0.000 seconds
<7>platform Fixed MDIO bus.0: LATE suspend
<7>serial8250 serial8250: LATE suspend
<7>serial8250 serial8250.0: LATE suspend
<7>fsl-gianfar_mdio fsl-gianfar_mdio.14: LATE suspend
<1>Unable to handle kernel paging request for instruction fetch
<1>Faulting instruction address: 0x616d6570
<1>Oops: Kernel access of bad area, sig: 11 [#1]
<1>MPC831x RDB
<1>Modules linked in: dsp rcspi modem i2c_mpc thermal_sys lm92 hwmon [last
unloaded: modem]
<1>NIP: 616d6570 LR: c0165224 CTR: 616d6573
<1>REGS: cd087d30 TRAP: 0400 Not tainted (2.6.27)
<1>MSR: 20001032 <ME,IR,DR> CR: 28002024 XER: 20000000
<1>TASK = cc312400[1196] 'echo' THREAD: cd086000
<6>GPR00: 00000002 cd087de0 cc312400 cf821800 cd087de8 00000002 c06e0000
c06da4a0
<6>GPR08: c06da948 616d6573 00003fff c06c6308 28002022 10091248 0fffc000
100050b8
<6>GPR16: 1008a270 10068810 100687c8 10068814 00000000 1008c284 1008c294
c0246180
<6>GPR24: c02ab9e4 c02ab9dc c06cc4f4 00000006 cd087e08 00000002 c06c595c
cf821808
<1>NIP [616d6570] 0x616d6570
<1>LR [c0165224] platform_pm_suspend_noirq+0x84/0x88
<1>Call Trace:
<1>[cd087de0] [c0167e6c] pm_dev_dbg+0x70/0x18c (unreliable)
<1>[cd087df0] [c0167cb4] pm_noirq_op+0x58/0xc8
<1>[cd087e00] [c0168e08] device_power_down+0x78/0x1c4
<1>[cd087e40] [c00471bc] suspend_devices_and_enter+0x1ec/0x258
<1>[cd087e70] [c00473ac] enter_state+0x13c/0x198
<1>[cd087e90] [c00474bc] state_store+0xb4/0xf8
<1>[cd087eb0] [c013af68] kobj_attr_store+0x24/0x3c
<1>[cd087ec0] [c00bf734] sysfs_write_file+0xe8/0x1e8
<1>[cd087ef0] [c0078bbc] vfs_write+0xb4/0x16c
<1>[cd087f10] [c0078d7c] sys_write+0x4c/0xa4
<1>[cd087f40] [c000fa88] ret_from_syscall+0x0/0x38
<1>--- Exception: c01 at 0x4802679c
<1> LR = 0x4803f0e8
<1>Instruction dump:
<1>XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
<1>XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
<4>---[ end trace b6a2457eea68b760 ]---
Segmentation fault
I tried commenting out the kernel code in drivers/base/platform.c ->
platform_legacy_suspend_late() function:
/* if (dev->driver && drv->suspend_late)
{ } */
This prevents the segmentation fault but it causes the resume functions for
all the peripherals to be called as soon as the suspend operations are
complete i.e. the processor goes into standby and then immediately goes
back to normal operation.
I found another thread that dealt with Power Management issues on the
Freescale MPC8313 processor:
https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-January/095240.html
The resolution of this issue seems to be related to the JTAG TRST pin being
disabled. This is not relevant in my case as the TRST on my board is
already inactive.
Any advice or suggestions are most welcome.
Thanks,
Srivatsan
[-- Attachment #2: Type: text/html, Size: 11569 bytes --]
^ permalink raw reply
* [PATCH RFT] powerpc: dma-mapping: support debug_dma_mapping_error
From: Shuah Khan @ 2012-10-26 0:16 UTC (permalink / raw)
To: benh, paulus, kyungmin.park, m.szyprowski, david, arnd, andrzej.p
Cc: linuxppc-dev, LKML, shuahkhan
Add support for debug_dma_mapping_error() call to avoid warning from
debug_dma_unmap() interface when it checks for mapping error checked
status. Without this patch, device driver failed to check map error
warning is generated.
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
---
arch/powerpc/include/asm/dma-mapping.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 7816087..e27e9ad 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -172,6 +172,7 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
+ debug_dma_mapping_error(dev, dma_addr);
if (dma_ops->mapping_error)
return dma_ops->mapping_error(dev, dma_addr);
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox