* Re: BookE "branch taken" behavior vis-a-vis updating the NIP register
From: James Yang @ 2013-11-13 17:20 UTC (permalink / raw)
To: pegasus; +Cc: linuxppc-dev
In-Reply-To: <1384241835150-78036.post@n7.nabble.com>
On Tue, 12 Nov 2013, pegasus wrote:
> So, off I went and downloaded the latest version of
> arch/powerpc/kernel/traps.c hoping to see those very changes in
> them. However it didn't match one on one with what was written in
> that thread. Ditto for the other files in your patch. Looks like
> your patch didn't make it to upstream but it looks exactly like what
> I need here.
The patches were posted RFC -- request for comment. Thank you for
posting your comments.
> So requesting PTRACE_CONT has to happen inside the SIGTRAP signal
> handler right?
After you get the SIGTRAP from the branch, yeah.
> Now as for the second patch, as far as I can see, implements the
> same functionality. However it makes the change permanent and any
> tool which is used to the NIP pointing to the branch target will be
> broken.
The second patch places the burden of determining if you are BookE or
server on the tool. I feel this is important because the Server and
Book-E branch exceptions are fundamentally incompatible, and the
behavior of PTRACE_SINGLEBLOCK can not be made to be identical by the
kernel for both subarch, so a tool will have to adjust accordingly.
> Anyways, for me either of them will work. But I think the first patch makes
> everyone happy by using the 'addr' field of ptrace. This also means I will
> have to make my (broken) ptrace working which, it seems is not as easy
> adding an enum field as you suggested. May be theres a check somewhere in
> the actual ptrace code which checks for illegal values and hence even after
> adding an enum, it is being reported as illegal in my case. However getting
> that to work is another story.
Actually, I provided the first patch to show why it probably should
not be done even though technically possible, since it requires ptrace
API to be extended to now recognize addr field, needs a TIF flag, etc.
The second patch seems to me more reasonable to support, since nobody
has come forth to say that there are actually any tools that rely upon
the existing hack for BookE or even PTRACE_SINGLEBLOCK. And the
existing hack's behavior makes things somewhat useless on BookE, as
you and I have confirmed.
> Please confirm my understanding of your patches and since these
> patches have not made their way to the upstream kernel, will have to
> use them myself directly. By the way, I'm using 2.6.32.10 (you
> know..the long-term kernel) and I couldn't find any of your changes
> in them but then again I couldn't find it in the latest 3.12 version
> either.
You will have to backport the patches to your kernel if you want to
use them. Both patches change the behavior of existing API, and I
guess we are still waiting to hear if anyone cares which way it should
be fixed.
^ permalink raw reply
* Re: [PATCH] Add a vga alias node for P1022
From: Scott Wood @ 2013-11-13 17:21 UTC (permalink / raw)
To: Jin Zhengxiong-R64188; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <13F8657A829DAB49A2A937FD6FC10F790B5CF17A@039-SN2MPN1-013.039d.mgd.msft.net>
On Wed, 2013-11-13 at 00:28 -0600, Jin Zhengxiong-R64188 wrote:
> > -----Original Message-----
> > From: Jin Zhengxiong-R64188
> > Sent: Friday, September 06, 2013 5:33 PM
> > To: Wood Scott-B07421
> > Cc: linuxppc-dev@lists.ozlabs.org; galak@kernel.crashing.org; Jin
> > Zhengxiong-R64188
> > Subject: [PATCH] Add a vga alias node for P1022
> >
> > From: Jason Jin <Jason.jin@freescale.com>
> >
> > When the vga was set as the stdout and stderr in u-boot, the stdout fixup
> > code in u-boot need to find out the vga alias node in dtb.
> >
> > Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> > ---
> > arch/powerpc/boot/dts/fsl/p1022si-post.dtsi | 2 +-
> > arch/powerpc/boot/dts/fsl/p1022si-pre.dtsi | 1 +
> > 2 files changed, 2 insertions(+), 1 deletion(-)
>
> [Jason Jin-R64188] Any comments about this patch? Thanks.
This isn't a VGA-compatible device. If this is needed by U-Boot, please
provide a comment explaining the compatibility issue, and ideally also
provide a display alias so that no other components grow dependencies on
the vga alias.
-Scott
^ permalink raw reply
* Re: Problem reading and programming memory location...
From: Anatolij Gustschin @ 2013-11-13 18:06 UTC (permalink / raw)
To: neorf3k; +Cc: Linux Ppc Dev List Dev List
In-Reply-To: <50EBA514-5BB1-40B3-B27B-309A829D2E05@gmail.com>
On Wed, 13 Nov 2013 14:48:24 +0100
neorf3k <neorf3k@gmail.com> wrote:
> Yes, that is a device on the lpb via an fpga. We have tried to configure
> the chip select 4 configuration register at address MBAR + 0x0310, and it
> seems to be ok. what do you mean with =E2=80=9Cchip select parameters=E2=
=80=9D?
I meant the settings you can set up in the Chip Select 1=E2=80=937 Configur=
ation
Registers, like address and data bus size, wait-states, etc.
> We have been able to edit it in U-BOOT, and the board (that chip) now wor=
ks=E2=80=A6
> The strange thing, is that when we read in linux, at that address, we see
> other content value=E2=80=A6
> Suggestions?
if you can access the register under U-Boot and read out the
expected values, then the access should work under Linux too,
assuming the chip select config is not overwritten somewhere
while booting and the register address range is mapped correctly.
I don't know your code, so I would first check if the register
mapping is done correctly, i.e. check the return value of ioremap()
for errors, then check if the chip select configuration is still
valid when the kernel is up. Also verify that your fpga is not
in the reset state when Linux is running.
thanks,
Anatolij
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-13 18:19 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev
In-Reply-To: <5282E52B.2040306@Freescale.com>
On Tue, 2013-11-12 at 20:34 -0600, Emil Medve wrote:
> Hello Scott,
>
>
> On 11/12/2013 07:46 PM, Scott Wood wrote:
> > On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
> >> Hello Scott,
> >>
> >>
> >> On 11/12/2013 04:04 PM, Scott Wood wrote:
> >>> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
> >>>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
> >>>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
> >>>>
> >>>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
> >>>> ---
> >>>> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
> >>>> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
> >>>> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
> >>>> 3 files changed, 35 insertions(+), 188 deletions(-)
> >>>> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
> >>>
> >>> Are we still going to want to have one defconfig if and when we finally
> >>> get datapath support upstream? That's a lot of code to add to the 85xx
> >>> config just for this one chip.
> >>
> >> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
> >> enabled by default given that just one SoC in that family has the
> >> datapath (and we don't plan to put it in another e500v2 based SoC). For
> >> regression/automation purposes config fragments should be used
> >
> > Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
> > whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
> > fragment?
>
> Not aware of it
Then it's not yet a substitute for having a defconfig.
> > Do we have any config fragments in the tree so far?
>
> Nope. However, just to make sure, the fragment was my secondary point
> and not necessarily as a candidate for upstreaming. My main point was
> that the datapath support should simply not be enabled by default in the
> mpc85xx_[smp_]defconfig
I think we should get numbers on how big the datapath code is (in its
eventual upstream form) before deciding that, but if we do end up
deciding not to enable it in mpc85xx_smp_defconfig, then there should be
a separate defconfig for p1023 (possibly with a more generic name as
discussed earlier). If and when there's support for defconfigs that
direct fragments to be included, then we can change the p1023 defconfig
to use that, but I don't want to just leave it up to the user to enable
manually.
If there's any way we can get the datapath code down to a reasonable
size for inclusion in mpc85xx_smp_defconfig, that would be ideal.
-Scott
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Emil Medve @ 2013-11-13 18:29 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1384366750.1403.154.camel@snotra.buserror.net>
Hello Scott,
On 11/13/2013 12:19 PM, Scott Wood wrote:
> On Tue, 2013-11-12 at 20:34 -0600, Emil Medve wrote:
>> Hello Scott,
>>
>>
>> On 11/12/2013 07:46 PM, Scott Wood wrote:
>>> On Tue, 2013-11-12 at 16:57 -0600, Emil Medve wrote:
>>>> Hello Scott,
>>>>
>>>>
>>>> On 11/12/2013 04:04 PM, Scott Wood wrote:
>>>>> On Mon, 2013-11-11 at 13:25 -0600, Lijun Pan wrote:
>>>>>> mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
>>>>>> Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
>>>>>>
>>>>>> Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
>>>>>> ---
>>>>>> arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
>>>>>> arch/powerpc/configs/mpc85xx_defconfig | 18 +++
>>>>>> arch/powerpc/configs/mpc85xx_smp_defconfig | 17 +++
>>>>>> 3 files changed, 35 insertions(+), 188 deletions(-)
>>>>>> delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
>>>>>
>>>>> Are we still going to want to have one defconfig if and when we finally
>>>>> get datapath support upstream? That's a lot of code to add to the 85xx
>>>>> config just for this one chip.
>>>>
>>>> Yes. But for mpc85xx_/smp_defconfig the datapath support shouldn't be
>>>> enabled by default given that just one SoC in that family has the
>>>> datapath (and we don't plan to put it in another e500v2 based SoC). For
>>>> regression/automation purposes config fragments should be used
>>>
>>> Is there any way to specify a meta-config for p1023 (or e500v2-dpaa or
>>> whatever) that says to combine mpc85xx_smp_defconfig with a dpaa
>>> fragment?
>>
>> Not aware of it
>
> Then it's not yet a substitute for having a defconfig.
>
>>> Do we have any config fragments in the tree so far?
>>
>> Nope. However, just to make sure, the fragment was my secondary point
>> and not necessarily as a candidate for upstreaming. My main point was
>> that the datapath support should simply not be enabled by default in the
>> mpc85xx_[smp_]defconfig
>
> I think we should get numbers on how big the datapath code is (in its
> eventual upstream form) before deciding that, but if we do end up
> deciding not to enable it in mpc85xx_smp_defconfig, then there should be
> a separate defconfig for p1023 (possibly with a more generic name as
> discussed earlier). If and when there's support for defconfigs that
> direct fragments to be included, then we can change the p1023 defconfig
> to use that, but I don't want to just leave it up to the user to enable
> manually.
>
> If there's any way we can get the datapath code down to a reasonable
> size for inclusion in mpc85xx_smp_defconfig, that would be ideal.
Somebody gratuitously added a P1023 defconfig more then two years ago
with the notion that P1023 is special due to its datapath and we're
still one year out before we'll have the (P1023) datapath driver
upstream. As of now this defconfig is just bit-rotting in the tree
creating confusion. Let's just remove it for now and we'll deal with the
entire e500v2_dpaa business when the datapath support will be upstreamed
Cheers,
^ permalink raw reply
* Re: [PATCH V2] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Scott Wood @ 2013-11-13 19:41 UTC (permalink / raw)
To: Emil Medve; +Cc: linuxppc-dev
In-Reply-To: <5283C51F.9090708@Freescale.com>
On Wed, 2013-11-13 at 12:29 -0600, Emil Medve wrote:
> Somebody gratuitously added a P1023 defconfig more then two years ago
> with the notion that P1023 is special due to its datapath and we're
> still one year out before we'll have the (P1023) datapath driver
> upstream. As of now this defconfig is just bit-rotting in the tree
> creating confusion. Let's just remove it for now and we'll deal with the
> entire e500v2_dpaa business when the datapath support will be upstreamed
Sure.
-Scott
^ permalink raw reply
* [PATCH v3] powerpc/85xx: Merge 85xx/p1023_defconfig into mpc85xx_smp_defconfig and mpc85xx_defconfig
From: Lijun Pan @ 2013-11-13 23:24 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lijun Pan
In-Reply-To: <1384197913-24610-1-git-send-email-Lijun.Pan@freescale.com>
mpc85xx_smp_defconfig and mpc85xx_defconfig already have CONFIG_P1023RDS=y.
Merge CONFIG_P1023RDB=y and other relevant configurations into mpc85xx_smp_defconfig and mpc85_defconfig.
Signed-off-by: Lijun Pan <Lijun.Pan@freescale.com>
---
arch/powerpc/configs/85xx/p1023_defconfig | 188 ----------------------------
arch/powerpc/configs/mpc85xx_defconfig | 3 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 3 +
3 files changed, 6 insertions(+), 188 deletions(-)
delete mode 100644 arch/powerpc/configs/85xx/p1023_defconfig
diff --git a/arch/powerpc/configs/85xx/p1023_defconfig b/arch/powerpc/configs/85xx/p1023_defconfig
deleted file mode 100644
index b06d37d..0000000
--- a/arch/powerpc/configs/85xx/p1023_defconfig
+++ /dev/null
@@ -1,188 +0,0 @@
-CONFIG_PPC_85xx=y
-CONFIG_SMP=y
-CONFIG_NR_CPUS=2
-CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
-CONFIG_BSD_PROCESS_ACCT=y
-CONFIG_AUDIT=y
-CONFIG_NO_HZ=y
-CONFIG_HIGH_RES_TIMERS=y
-CONFIG_RCU_FANOUT=32
-CONFIG_IKCONFIG=y
-CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=14
-CONFIG_BLK_DEV_INITRD=y
-CONFIG_KALLSYMS_ALL=y
-CONFIG_EMBEDDED=y
-CONFIG_MODULES=y
-CONFIG_MODULE_UNLOAD=y
-CONFIG_MODULE_FORCE_UNLOAD=y
-CONFIG_MODVERSIONS=y
-# CONFIG_BLK_DEV_BSG is not set
-CONFIG_PARTITION_ADVANCED=y
-CONFIG_MAC_PARTITION=y
-CONFIG_PHYSICAL_START=0x00000000
-CONFIG_P1023_RDB=y
-CONFIG_P1023_RDS=y
-CONFIG_QUICC_ENGINE=y
-CONFIG_QE_GPIO=y
-CONFIG_CPM2=y
-CONFIG_HIGHMEM=y
-# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
-CONFIG_BINFMT_MISC=m
-CONFIG_MATH_EMULATION=y
-CONFIG_SWIOTLB=y
-CONFIG_PCI=y
-CONFIG_PCIEPORTBUS=y
-# CONFIG_PCIEAER is not set
-# CONFIG_PCIEASPM is not set
-CONFIG_PCI_MSI=y
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_XFRM_USER=y
-CONFIG_NET_KEY=y
-CONFIG_INET=y
-CONFIG_IP_MULTICAST=y
-CONFIG_IP_ADVANCED_ROUTER=y
-CONFIG_IP_MULTIPLE_TABLES=y
-CONFIG_IP_ROUTE_MULTIPATH=y
-CONFIG_IP_ROUTE_VERBOSE=y
-CONFIG_IP_PNP=y
-CONFIG_IP_PNP_DHCP=y
-CONFIG_IP_PNP_BOOTP=y
-CONFIG_IP_PNP_RARP=y
-CONFIG_NET_IPIP=y
-CONFIG_IP_MROUTE=y
-CONFIG_IP_PIMSM_V1=y
-CONFIG_IP_PIMSM_V2=y
-CONFIG_ARPD=y
-CONFIG_INET_ESP=y
-# CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
-CONFIG_IPV6=y
-CONFIG_IP_SCTP=m
-CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
-CONFIG_DEVTMPFS=y
-CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_MTD=y
-CONFIG_MTD_CMDLINE_PARTS=y
-CONFIG_MTD_CHAR=y
-CONFIG_MTD_BLOCK=y
-CONFIG_MTD_CFI=y
-CONFIG_MTD_CFI_AMDSTD=y
-CONFIG_MTD_PHYSMAP_OF=y
-CONFIG_MTD_NAND=y
-CONFIG_MTD_NAND_FSL_ELBC=y
-CONFIG_PROC_DEVICETREE=y
-CONFIG_BLK_DEV_LOOP=y
-CONFIG_BLK_DEV_RAM=y
-CONFIG_BLK_DEV_RAM_SIZE=131072
-CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_LEGACY=y
-CONFIG_BLK_DEV_SD=y
-CONFIG_CHR_DEV_ST=y
-CONFIG_BLK_DEV_SR=y
-CONFIG_CHR_DEV_SG=y
-CONFIG_SCSI_MULTI_LUN=y
-CONFIG_SCSI_LOGGING=y
-CONFIG_ATA=y
-CONFIG_SATA_FSL=y
-CONFIG_SATA_SIL24=y
-CONFIG_NETDEVICES=y
-CONFIG_DUMMY=y
-CONFIG_FS_ENET=y
-CONFIG_FSL_PQ_MDIO=y
-CONFIG_E1000E=y
-CONFIG_PHYLIB=y
-CONFIG_AT803X_PHY=y
-CONFIG_MARVELL_PHY=y
-CONFIG_DAVICOM_PHY=y
-CONFIG_CICADA_PHY=y
-CONFIG_VITESSE_PHY=y
-CONFIG_FIXED_PHY=y
-CONFIG_INPUT_FF_MEMLESS=m
-# CONFIG_INPUT_MOUSEDEV is not set
-# CONFIG_INPUT_KEYBOARD is not set
-# CONFIG_INPUT_MOUSE is not set
-CONFIG_SERIO_LIBPS2=y
-CONFIG_SERIAL_8250=y
-CONFIG_SERIAL_8250_CONSOLE=y
-CONFIG_SERIAL_8250_NR_UARTS=2
-CONFIG_SERIAL_8250_RUNTIME_UARTS=2
-CONFIG_SERIAL_8250_EXTENDED=y
-CONFIG_SERIAL_8250_MANY_PORTS=y
-CONFIG_SERIAL_8250_SHARE_IRQ=y
-CONFIG_SERIAL_8250_DETECT_IRQ=y
-CONFIG_SERIAL_8250_RSA=y
-CONFIG_HW_RANDOM=y
-CONFIG_NVRAM=y
-CONFIG_I2C=y
-CONFIG_I2C_CHARDEV=y
-CONFIG_I2C_CPM=m
-CONFIG_I2C_MPC=y
-CONFIG_GPIO_MPC8XXX=y
-# CONFIG_HWMON is not set
-CONFIG_VIDEO_OUTPUT_CONTROL=y
-CONFIG_SOUND=y
-CONFIG_SND=y
-CONFIG_SND_MIXER_OSS=y
-CONFIG_SND_PCM_OSS=y
-# CONFIG_SND_SUPPORT_OLD_API is not set
-CONFIG_USB=y
-CONFIG_USB_DEVICEFS=y
-CONFIG_USB_MON=y
-CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_FSL=y
-CONFIG_USB_STORAGE=y
-CONFIG_EDAC=y
-CONFIG_EDAC_MM_EDAC=y
-CONFIG_RTC_CLASS=y
-CONFIG_RTC_DRV_DS1307=y
-CONFIG_RTC_DRV_CMOS=y
-CONFIG_DMADEVICES=y
-CONFIG_FSL_DMA=y
-# CONFIG_NET_DMA is not set
-CONFIG_STAGING=y
-CONFIG_EXT2_FS=y
-CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-CONFIG_ISO9660_FS=m
-CONFIG_JOLIET=y
-CONFIG_ZISOFS=y
-CONFIG_UDF_FS=m
-CONFIG_MSDOS_FS=m
-CONFIG_VFAT_FS=y
-CONFIG_NTFS_FS=y
-CONFIG_PROC_KCORE=y
-CONFIG_TMPFS=y
-CONFIG_ADFS_FS=m
-CONFIG_AFFS_FS=m
-CONFIG_HFS_FS=m
-CONFIG_HFSPLUS_FS=m
-CONFIG_BEFS_FS=m
-CONFIG_BFS_FS=m
-CONFIG_EFS_FS=m
-CONFIG_CRAMFS=y
-CONFIG_VXFS_FS=m
-CONFIG_HPFS_FS=m
-CONFIG_QNX4FS_FS=m
-CONFIG_SYSV_FS=m
-CONFIG_UFS_FS=m
-CONFIG_NFS_FS=y
-CONFIG_NFS_V4=y
-CONFIG_ROOT_NFS=y
-CONFIG_NFSD=y
-CONFIG_CRC_T10DIF=y
-CONFIG_FRAME_WARN=8092
-CONFIG_DEBUG_FS=y
-CONFIG_DETECT_HUNG_TASK=y
-# CONFIG_DEBUG_BUGVERBOSE is not set
-CONFIG_DEBUG_INFO=y
-CONFIG_STRICT_DEVMEM=y
-CONFIG_CRYPTO_PCBC=m
-CONFIG_CRYPTO_SHA256=y
-CONFIG_CRYPTO_SHA512=y
-CONFIG_CRYPTO_AES=y
-# CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_CRYPTO_DEV_FSL_CAAM=y
diff --git a/arch/powerpc/configs/mpc85xx_defconfig b/arch/powerpc/configs/mpc85xx_defconfig
index d2e0fab..83d3550 100644
--- a/arch/powerpc/configs/mpc85xx_defconfig
+++ b/arch/powerpc/configs/mpc85xx_defconfig
@@ -31,6 +31,7 @@ CONFIG_C293_PCIE=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
+CONFIG_P1023_RDB=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
@@ -113,6 +114,7 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_LEGACY=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
@@ -211,6 +213,7 @@ CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_CMOS=y
+CONFIG_RTC_DRV_DS1307=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
# CONFIG_NET_DMA is not set
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index 4cb7b59..4b68629 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -34,6 +34,7 @@ CONFIG_C293_PCIE=y
CONFIG_P1010_RDB=y
CONFIG_P1022_DS=y
CONFIG_P1022_RDK=y
+CONFIG_P1023_RDB=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
@@ -116,6 +117,7 @@ CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=y
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_LEGACY=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
@@ -212,6 +214,7 @@ CONFIG_EDAC=y
CONFIG_EDAC_MM_EDAC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_CMOS=y
+CONFIG_RTC_DRV_DS1307=y
CONFIG_DMADEVICES=y
CONFIG_FSL_DMA=y
# CONFIG_NET_DMA is not set
--
1.7.9.7
^ permalink raw reply related
* [PATCH] powerpc: fix __get_user_pages_fast() irq handling
From: Benjamin Herrenschmidt @ 2013-11-14 4:01 UTC (permalink / raw)
To: linuxppc-dev list; +Cc: Heiko Carstens
From: Heiko Carstens <heiko.carstens@de.ibm.com>
__get_user_pages_fast() may be called with interrupts disabled (see e.g.
get_futex_key() in kernel/futex.c) and therefore should use local_irq_save()
and local_irq_restore() instead of local_irq_disable()/enable().
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
(Was originally sent to lkml only, sending to linuxppc-dev so patchwork gets it)
arch/powerpc/mm/gup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
index 6936547..c5f734e 100644
--- a/arch/powerpc/mm/gup.c
+++ b/arch/powerpc/mm/gup.c
@@ -123,6 +123,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
struct mm_struct *mm = current->mm;
unsigned long addr, len, end;
unsigned long next;
+ unsigned long flags;
pgd_t *pgdp;
int nr = 0;
@@ -156,7 +157,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
* So long as we atomically load page table pointers versus teardown,
* we can follow the address down to the the page and take a ref on it.
*/
- local_irq_disable();
+ local_irq_save(flags);
pgdp = pgd_offset(mm, addr);
do {
@@ -179,7 +180,7 @@ int __get_user_pages_fast(unsigned long start, int nr_pages, int write,
break;
} while (pgdp++, addr = next, addr != end);
- local_irq_enable();
+ local_irq_restore(flags);
return nr;
}
--
1.8.3.4
^ permalink raw reply related
* RE: [PATCH] Add a vga alias node for P1022
From: Zhengxiong Jin @ 2013-11-14 7:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1384363303.1403.143.camel@snotra.buserror.net>
DQo+ID4gPg0KPiA+ID4gV2hlbiB0aGUgdmdhIHdhcyBzZXQgYXMgdGhlIHN0ZG91dCBhbmQgc3Rk
ZXJyIGluIHUtYm9vdCwgdGhlIHN0ZG91dA0KPiA+ID4gZml4dXAgY29kZSBpbiB1LWJvb3QgbmVl
ZCB0byBmaW5kIG91dCB0aGUgdmdhIGFsaWFzIG5vZGUgaW4gZHRiLg0KPiA+ID4NCj4gPiA+IFNp
Z25lZC1vZmYtYnk6IEphc29uIEppbiA8SmFzb24uamluQGZyZWVzY2FsZS5jb20+DQo+ID4gPiAt
LS0NCj4gPiA+ICBhcmNoL3Bvd2VycGMvYm9vdC9kdHMvZnNsL3AxMDIyc2ktcG9zdC5kdHNpIHwg
MiArLQ0KPiA+ID4gYXJjaC9wb3dlcnBjL2Jvb3QvZHRzL2ZzbC9wMTAyMnNpLXByZS5kdHNpICB8
IDEgKw0KPiA+ID4gIDIgZmlsZXMgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9u
KC0pDQo+ID4NCj4gPiBbSmFzb24gSmluLVI2NDE4OF0gQW55IGNvbW1lbnRzIGFib3V0IHRoaXMg
cGF0Y2g/IFRoYW5rcy4NCj4gDQo+IFRoaXMgaXNuJ3QgYSBWR0EtY29tcGF0aWJsZSBkZXZpY2Uu
ICBJZiB0aGlzIGlzIG5lZWRlZCBieSBVLUJvb3QsIHBsZWFzZQ0KPiBwcm92aWRlIGEgY29tbWVu
dCBleHBsYWluaW5nIHRoZSBjb21wYXRpYmlsaXR5IGlzc3VlLCBhbmQgaWRlYWxseSBhbHNvDQo+
IHByb3ZpZGUgYSBkaXNwbGF5IGFsaWFzIHNvIHRoYXQgbm8gb3RoZXIgY29tcG9uZW50cyBncm93
IGRlcGVuZGVuY2llcyBvbg0KPiB0aGUgdmdhIGFsaWFzLg0KPiANCj4gLVNjb3R0DQo+IA0KW0ph
c29uIEppbi1SNjQxODhdIFRoYW5rcywgd2lsbCBhZGQgZGVzY3JpcHRpb24gZm9yIHdoeSB0aGUg
dmdhIGFsaWFzIG5vZGUgaXMgbmVlZGVkIGJ5IHUtYm9vdCwgYW5kIGFkZCBhbm90aGVyIGRpc3Bs
YXkgYWxpYXMgbm9kZS4NCg==
^ permalink raw reply
* Re: Problem reading and programming memory location...
From: neorf3k @ 2013-11-14 8:38 UTC (permalink / raw)
To: Anatolij Gustschin
In-Reply-To: <20131113190606.2a5d08fb@crub>
Thank you again=85
we have checked, and the settings in Chip Select 4 Configuration, seems =
to be ok=85
The strange thing is the return value from ioremap(). In U-Boot return =
value from address 0x1002000 is 0x45f80360=85 if we try to map it in our =
module, then we use ioremap(), return value is 0x10101010. So maybe the =
register address is mapped wrong=85 what could i fix it?
Then, after we have setted up the reg at 0x1002000 and we boot linux=85 =
the 0x1002000 doesn=92t change its value=85=20
Thanks again=85
Lorenzo
On 13/nov/2013, at 07:06 PM, Anatolij Gustschin <agust@denx.de> wrote:
> On Wed, 13 Nov 2013 14:48:24 +0100
> neorf3k <neorf3k@gmail.com> wrote:
>=20
>> Yes, that is a device on the lpb via an fpga. We have tried to =
configure
>> the chip select 4 configuration register at address MBAR + 0x0310, =
and it
>> seems to be ok. what do you mean with =93chip select parameters=94?
>=20
> I meant the settings you can set up in the Chip Select 1=967 =
Configuration
> Registers, like address and data bus size, wait-states, etc.
>=20
>> We have been able to edit it in U-BOOT, and the board (that chip) now =
works=85
>> The strange thing, is that when we read in linux, at that address, we =
see
>> other content value=85
>> Suggestions?
>=20
> if you can access the register under U-Boot and read out the
> expected values, then the access should work under Linux too,
> assuming the chip select config is not overwritten somewhere
> while booting and the register address range is mapped correctly.
> I don't know your code, so I would first check if the register
> mapping is done correctly, i.e. check the return value of ioremap()
> for errors, then check if the chip select configuration is still
> valid when the kernel is up. Also verify that your fpga is not
> in the reset state when Linux is running.
>=20
> thanks,
>=20
> Anatolij
^ permalink raw reply
* Re: [PATCH 00/11] Consolidate asm/fixmap.h files
From: Michal Simek @ 2013-11-14 9:39 UTC (permalink / raw)
To: Mark Salter
Cc: linux-arch, linux-mips, James Hogan, Russell King, Arnd Bergmann,
linux-hexagon, linux-kernel, Ralf Baechle, Richard Kuo,
microblaze-uclinux, Paul Mackerras, linuxppc-dev, linux-metag,
linux-arm-kernel
In-Reply-To: <1384271711.24631.5.camel@deneb.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]
On 11/12/2013 04:55 PM, Mark Salter wrote:
> On Tue, 2013-11-12 at 16:39 +0100, Michal Simek wrote:
>> On 11/12/2013 02:22 PM, Mark Salter wrote:
>>>
>>> arch/arm/include/asm/fixmap.h | 25 ++------
>>> arch/hexagon/include/asm/fixmap.h | 40 +------------
>>> arch/metag/include/asm/fixmap.h | 32 +----------
>>> arch/microblaze/include/asm/fixmap.h | 44 +-------------
>>> arch/mips/include/asm/fixmap.h | 33 +----------
>>> arch/powerpc/include/asm/fixmap.h | 44 +-------------
>>> arch/sh/include/asm/fixmap.h | 39 +------------
>>> arch/tile/include/asm/fixmap.h | 33 +----------
>>> arch/um/include/asm/fixmap.h | 40 +------------
>>> arch/x86/include/asm/fixmap.h | 59 +------------------
>>> include/asm-generic/fixmap.h | 107 +++++++++++++++++++++++++++++++++++
>>> 11 files changed, 125 insertions(+), 371 deletions(-)
>>> create mode 100644 include/asm-generic/fixmap.h
>>
>> Any repo/branch with all these patches will be helpful.
>
> https://github.com/mosalter/linux (fixmap branch)
Thanks,
For Microblaze
Tested-by: Michal Simek <monstr@monstr.eu>
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: Problem reading and programming memory location...
From: neorf3k @ 2013-11-14 9:49 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: Linux Ppc Dev List Dev List
In-Reply-To: <20131114100917.31f674d7@crub>
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
Sorry, the address is 0x10020000.
I've executed this code:
/* code */
unsigned char *virt_base;
u8 regval;
/* map 4kbyte reg. space */
virt_base = ioremap(0x10020000, 0x1000);
if (!virt_base) {
printk("fpga ioremap failed\n");
return;
}
regval = in_8(virt_base);
printk("reg. value 0x%02x\n", regval);
printk("reg. value %x\n", virt_base);
/* code */
and i've:
reg. value 0x10
address c90e8000
in U-BOOT in reg. value i've: 0xf8
Thank you so much again…
Lorenzo
On 14/nov/2013, at 10:09 AM, Anatolij Gustschin <agust@denx.de> wrote:
> u8 regval;
>
> /* map 4kbyte reg. space */
> virt_base = ioremap(0x10020000, 0x1000);
> if (!virt_base) {
> printk("fpga ioremap failed\n");
> return;
> }
>
> regval = in_8(virt_base);
>
> printk("reg. value 0x%02x\n", regval);
[-- Attachment #2: Type: text/html, Size: 8691 bytes --]
^ permalink raw reply
* [PATCH 0/2] Add monaural audio support for fsl_ssi.c
From: Nicolin Chen @ 2013-11-14 11:07 UTC (permalink / raw)
To: timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, swarren, linux-kernel, rob.herring, lgirdwood,
linuxppc-dev, linux-arm-kernel
This series of patches need to be applied into one single tree because
the second patch depends on the first one. Without it, SSI would playback
constant noise to the right channel when playback monaural audio files on
i.MX6 Series board.
We might also need to apply the iomux change to the other i.MX platforms,
just currently I don't have those boards so I drop their changes for now.
Nicolin Chen (2):
ARM: dts: imx: specify the value of audmux pinctrl instead of
0x80000000
ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface
arch/arm/boot/dts/imx6qdl.dtsi | 22 +++++++++++-----------
sound/soc/fsl/fsl_ssi.c | 22 +++++++++++++++++++---
2 files changed, 30 insertions(+), 14 deletions(-)
--
1.8.4
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx: specify the value of audmux pinctrl instead of 0x80000000
From: Nicolin Chen @ 2013-11-14 11:07 UTC (permalink / raw)
To: timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, swarren, linux-kernel, rob.herring, lgirdwood,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1384427230-979-1-git-send-email-b42378@freescale.com>
We must specify the value of audmux pinctrl if we want to use pinctrl_pm().
Thus change bypass value 0x80000000 to what we exactly need.
This patch also seperately unset PUE bit for TXD so that IOMUX won't pull
up/down the pin after turning into tristate. When we use SSI normal mode to
playback monaural audio via I2S signal, there'd be a pulled curve occur to
its signal at the second slot if setting PUE bit for TXD. And it will make
the second channel to play a constant noise. So by keeping the signal level
in the second slot, we can get a constant high level signal (-1) or a low
level one (0).
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6e096ca..6b76e55 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -601,27 +601,27 @@
audmux {
pinctrl_audmux_1: audmux-1 {
fsl,pins = <
- MX6QDL_PAD_SD2_DAT0__AUD4_RXD 0x80000000
- MX6QDL_PAD_SD2_DAT3__AUD4_TXC 0x80000000
- MX6QDL_PAD_SD2_DAT2__AUD4_TXD 0x80000000
- MX6QDL_PAD_SD2_DAT1__AUD4_TXFS 0x80000000
+ MX6QDL_PAD_SD2_DAT0__AUD4_RXD 0x130b0
+ MX6QDL_PAD_SD2_DAT3__AUD4_TXC 0x130b0
+ MX6QDL_PAD_SD2_DAT2__AUD4_TXD 0x110b0
+ MX6QDL_PAD_SD2_DAT1__AUD4_TXFS 0x130b0
>;
};
pinctrl_audmux_2: audmux-2 {
fsl,pins = <
- MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x80000000
- MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x80000000
- MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x80000000
- MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x80000000
+ MX6QDL_PAD_CSI0_DAT7__AUD3_RXD 0x130b0
+ MX6QDL_PAD_CSI0_DAT4__AUD3_TXC 0x130b0
+ MX6QDL_PAD_CSI0_DAT5__AUD3_TXD 0x110b0
+ MX6QDL_PAD_CSI0_DAT6__AUD3_TXFS 0x130b0
>;
};
pinctrl_audmux_3: audmux-3 {
fsl,pins = <
- MX6QDL_PAD_DISP0_DAT16__AUD5_TXC 0x80000000
- MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x80000000
- MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x80000000
+ MX6QDL_PAD_DISP0_DAT16__AUD5_TXC 0x130b0
+ MX6QDL_PAD_DISP0_DAT18__AUD5_TXFS 0x130b0
+ MX6QDL_PAD_DISP0_DAT19__AUD5_RXD 0x130b0
>;
};
};
--
1.8.4
^ permalink raw reply related
* [PATCH 2/2] ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface
From: Nicolin Chen @ 2013-11-14 11:07 UTC (permalink / raw)
To: timur, shawn.guo, broonie
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, swarren, linux-kernel, rob.herring, lgirdwood,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <1384427230-979-1-git-send-email-b42378@freescale.com>
The normal mode of SSI allows it to send/receive data to/from the first
slot of each period. So we can use this normal mode to trick I2S signal
by puting/getting data to/from the first slot only (the left channel)
so as to support monaural audio playback and recording.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
sound/soc/fsl/fsl_ssi.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index f43be6d..ccf1d38 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -517,10 +517,12 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream,
{
struct fsl_ssi_private *ssi_private = snd_soc_dai_get_drvdata(cpu_dai);
struct ccsr_ssi __iomem *ssi = ssi_private->ssi;
+ unsigned int channels = params_channels(hw_params);
unsigned int sample_size =
snd_pcm_format_width(params_format(hw_params));
u32 wl = CCSR_SSI_SxCCR_WL(sample_size);
int enabled = read_ssi(&ssi->scr) & CCSR_SSI_SCR_SSIEN;
+ static u8 i2s_mode;
/*
* If we're in synchronous mode, and the SSI is already enabled,
@@ -546,6 +548,21 @@ static int fsl_ssi_hw_params(struct snd_pcm_substream *substream,
else
write_ssi_mask(&ssi->srccr, CCSR_SSI_SxCCR_WL_MASK, wl);
+ if (ssi_private->imx_ac97)
+ return 0;
+
+ /* Save i2s mode configuration so that we can restore it later */
+ switch (read_ssi(&ssi->scr) & CCSR_SSI_SCR_I2S_MODE_MASK) {
+ case CCSR_SSI_SCR_I2S_MODE_SLAVE:
+ case CCSR_SSI_SCR_I2S_MODE_MASTER:
+ i2s_mode = read_ssi(&ssi->scr) & CCSR_SSI_SCR_I2S_MODE_MASK;
+ default:
+ break;
+ }
+
+ write_ssi_mask(&ssi->scr, CCSR_SSI_SCR_NET | CCSR_SSI_SCR_I2S_MODE_MASK,
+ channels == 1 ? 0 : CCSR_SSI_SCR_NET | i2s_mode);
+
return 0;
}
@@ -658,14 +675,13 @@ static const struct snd_soc_dai_ops fsl_ssi_dai_ops = {
static struct snd_soc_dai_driver fsl_ssi_dai_template = {
.probe = fsl_ssi_dai_probe,
.playback = {
- /* The SSI does not support monaural audio. */
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = FSLSSI_I2S_RATES,
.formats = FSLSSI_I2S_FORMATS,
},
.capture = {
- .channels_min = 2,
+ .channels_min = 1,
.channels_max = 2,
.rates = FSLSSI_I2S_RATES,
.formats = FSLSSI_I2S_FORMATS,
--
1.8.4
^ permalink raw reply related
* [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Haiying Wang @ 2013-11-14 19:30 UTC (permalink / raw)
To: joro, iommu, linuxppc-dev; +Cc: Varun Sethi
In the case we miss to bring up some cpus, we need to make sure we can
find the correct cpu nodes in the device tree based on the given logical
cpu index from the caller.
Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
---
drivers/iommu/fsl_pamu.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
index cba0498..a9ab57b 100644
--- a/drivers/iommu/fsl_pamu.c
+++ b/drivers/iommu/fsl_pamu.c
@@ -539,6 +539,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
u32 cache_level;
int len, found = 0;
int i;
+ u32 cpuid = get_hard_smp_processor_id(vcpu);
/* Fastpath, exit early if L3/CPC cache is target for stashing */
if (stash_dest_hint == PAMU_ATTR_CACHE_L3) {
@@ -559,7 +560,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
for_each_node_by_type(node, "cpu") {
prop = of_get_property(node, "reg", &len);
for (i = 0; i < len / sizeof(u32); i++) {
- if (be32_to_cpup(&prop[i]) == vcpu) {
+ if (be32_to_cpup(&prop[i]) == cpuid) {
found = 1;
goto found_cpu_node;
}
--
1.7.3.1.50.g1e633
^ permalink raw reply related
* Re: [PATCH RFC v5 2/5] dma: mpc512x: add support for peripheral transfers
From: Gerhard Sittig @ 2013-11-14 20:58 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree, Lars-Peter Clausen, Arnd Bergmann, Vinod Koul,
Dan Williams, Anatolij Gustschin, linuxppc-dev
In-Reply-To: <CAF0T0X5mCEiS88YGGjSS6oGU5RaQ=2PEQFL533OjpQzmc398rA@mail.gmail.com>
On Tue, Nov 12, 2013 at 16:23 +0400, Alexander Popov wrote:
>
> 2013/11/12 Gerhard Sittig <gsi@denx.de>:
> >
> > It would be nice to get a response to the feedback that you
> > are given. It may be appropriate not to obey to the
> > feedback, but at least it should get considered.
>
> Yes, I see. My implicit response by RFCv5 was not efficient,
> sorry. Now should I write a detailed answer in the thread with
> your feedback for improving readability of the discussion?
Don't you have a checklist of which feedback you got and which of
it you did address and which you didn't? Reviewers don't usually
do the tracking for those who do the submissions.
I think that you may list "pending issues" or "non-issues" either
with new submissions or at the previous version's feedback,
whatever is more appropriate. Maybe "pending" is useful with the
new announcement, while "won't, need not" is better kept with the
reviews.
As for the not yet addressed feedback: From the top of my head I
can think of the execute comment which contradicts the code
(which suggests that at least one of them is wrong), and the data
type mismatch in the config routine (where code just happens to
work by coincidence). And in bypassing I noticed that your
recent submission has coding style issues (braces, indentation),
which should no longer happen after several iterations as you
should know how to prepare and check the next version.
Again: It may be OK to not follow the advice (especially if you
get multiple responses of differrent direction, or when you are
more familiar with the subject than an observer). But you should
state when you don't agree and why. Without feedback, reviewers
may see several submissions which suffer from the same issues,
and expect more to show up and thus feel that their feedback is
getting ignored. Which quickly becomes tiring.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Scott Wood @ 2013-11-14 22:10 UTC (permalink / raw)
To: Haiying Wang; +Cc: Varun Sethi, joro, linuxppc-dev, iommu
In-Reply-To: <1384457440.2144.15.camel@haiying-laptop>
On Thu, 2013-11-14 at 14:30 -0500, Haiying Wang wrote:
> In the case we miss to bring up some cpus, we need to make sure we can
> find the correct cpu nodes in the device tree based on the given logical
> cpu index from the caller.
>
> Signed-off-by: Haiying Wang <Haiying.Wang@freescale.com>
> ---
> drivers/iommu/fsl_pamu.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index cba0498..a9ab57b 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -539,6 +539,7 @@ u32 get_stash_id(u32 stash_dest_hint, u32 vcpu)
Should probably also s/vcpu/cpu/g as vcpu makes no sense outside of
virtualization code.
> u32 cache_level;
> int len, found = 0;
> int i;
> + u32 cpuid = get_hard_smp_processor_id(vcpu);
s/cpuid/phys_cpu/ or similar
-Scott
^ permalink raw reply
* Re: [PATCH 0/2] Add monaural audio support for fsl_ssi.c
From: Shawn Guo @ 2013-11-15 3:02 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, lgirdwood, swarren, timur, rob.herring,
linux-kernel, broonie, linuxppc-dev, linux-arm-kernel
In-Reply-To: <1384427230-979-1-git-send-email-b42378@freescale.com>
On Thu, Nov 14, 2013 at 07:07:08PM +0800, Nicolin Chen wrote:
> This series of patches need to be applied into one single tree because
> the second patch depends on the first one. Without it, SSI would playback
> constant noise to the right channel when playback monaural audio files on
> i.MX6 Series board.
Let me try to understand if the dependency is true.
Saying I apply the DTS patch on IMX tree while Mark apply the fsl_ssi
patch on his tree, will there be any regression on either IMX tree or
Mark's tree? The monaural playback on imx6qdl never worked, so it's not
a regression. If there is no regression on either tree, there is no
dependency to maintain.
Shawn
>
> We might also need to apply the iomux change to the other i.MX platforms,
> just currently I don't have those boards so I drop their changes for now.
>
> Nicolin Chen (2):
> ARM: dts: imx: specify the value of audmux pinctrl instead of
> 0x80000000
> ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface
>
> arch/arm/boot/dts/imx6qdl.dtsi | 22 +++++++++++-----------
> sound/soc/fsl/fsl_ssi.c | 22 +++++++++++++++++++---
> 2 files changed, 30 insertions(+), 14 deletions(-)
>
> --
> 1.8.4
>
>
^ permalink raw reply
* Re: [PATCH 0/2] Add monaural audio support for fsl_ssi.c
From: Nicolin Chen @ 2013-11-15 2:59 UTC (permalink / raw)
To: Shawn Guo
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, lgirdwood, swarren, timur, rob.herring,
linux-kernel, broonie, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20131115030247.GC11014@S2101-09.ap.freescale.net>
Hi Shawn,
On Fri, Nov 15, 2013 at 11:02:49AM +0800, Shawn Guo wrote:
> On Thu, Nov 14, 2013 at 07:07:08PM +0800, Nicolin Chen wrote:
> > This series of patches need to be applied into one single tree because
> > the second patch depends on the first one. Without it, SSI would playback
> > constant noise to the right channel when playback monaural audio files on
> > i.MX6 Series board.
>
> Let me try to understand if the dependency is true.
>
> Saying I apply the DTS patch on IMX tree while Mark apply the fsl_ssi
> patch on his tree, will there be any regression on either IMX tree or
> Mark's tree? The monaural playback on imx6qdl never worked, so it's not
> a regression. If there is no regression on either tree, there is no
> dependency to maintain.
It's fair enough to understand in this way. It looks like I misunderstood
the dependency here.
Do I need to resend them separately?
Thank you.
>
> Shawn
>
> >
> > We might also need to apply the iomux change to the other i.MX platforms,
> > just currently I don't have those boards so I drop their changes for now.
> >
> > Nicolin Chen (2):
> > ARM: dts: imx: specify the value of audmux pinctrl instead of
> > 0x80000000
> > ASoC: fsl_ssi: Add monaural audio support for non-ac97 interface
> >
> > arch/arm/boot/dts/imx6qdl.dtsi | 22 +++++++++++-----------
> > sound/soc/fsl/fsl_ssi.c | 22 +++++++++++++++++++---
> > 2 files changed, 30 insertions(+), 14 deletions(-)
> >
> > --
> > 1.8.4
> >
> >
^ permalink raw reply
* RE: [PATCH] iommu/fsl_pamu: use physical cpu index to find the matched cpu nodes
From: Varun Sethi @ 2013-11-15 3:16 UTC (permalink / raw)
To: Scott Wood, Haiying Wang
Cc: joro@8bytes.org, linuxppc-dev@lists.ozlabs.org,
iommu@lists.linux-foundation.org
In-Reply-To: <1384467025.1403.210.camel@snotra.buserror.net>
SGFpeWluZy9TY290dCwNCkZvcmdvdCB0byBtZW50aW9uIHRoaXMsIHRoZSBQQU1VIGRyaXZlciBo
YXMgdG8gaGFuZGxlIHN0YXNoIGRlc3RpbmF0aW9uIHNldHRpbmdzIGJvdGggZm9yIHBvd2VyIGFu
ZCBkc3AgY29yZXMgKG9uIEI0IHBsYXRmb3JtKS4gRm9yIHRoZSBkc3AgY29yZXMgd2Ugd291bGQg
ZXhwZWN0IHRoZSBwaHlzaWNhbCBjb3JlIGlkIChub3QgY29udHJvbGxlZCBieSBMaW51eCkuIFRv
IG1ha2UgdGhlIGludGVyZmFjZSBjb25zaXN0ZW50LCBJIHdvdWxkIGV4cGVjdCB0aGUgY2FsbGVy
IChmb3IgaW9tbXVfc2V0X2F0dHIpIHRvIHBhc3MgdGhlIHBoeXNpY2FsIGNvcmUgaWQuDQoNClJl
Z2FyZHMNClZhcnVuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV29v
ZCBTY290dC1CMDc0MjENCj4gU2VudDogRnJpZGF5LCBOb3ZlbWJlciAxNSwgMjAxMyAzOjQwIEFN
DQo+IFRvOiBXYW5nIEhhaXlpbmctUjU0OTY0DQo+IENjOiBqb3JvQDhieXRlcy5vcmc7IGlvbW11
QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnOyBsaW51eHBwYy0NCj4gZGV2QGxpc3RzLm96bGFi
cy5vcmc7IFNldGhpIFZhcnVuLUIxNjM5NQ0KPiBTdWJqZWN0OiBSZTogW1BBVENIXSBpb21tdS9m
c2xfcGFtdTogdXNlIHBoeXNpY2FsIGNwdSBpbmRleCB0byBmaW5kIHRoZQ0KPiBtYXRjaGVkIGNw
dSBub2Rlcw0KPiANCj4gT24gVGh1LCAyMDEzLTExLTE0IGF0IDE0OjMwIC0wNTAwLCBIYWl5aW5n
IFdhbmcgd3JvdGU6DQo+ID4gSW4gdGhlIGNhc2Ugd2UgbWlzcyB0byBicmluZyB1cCBzb21lIGNw
dXMsIHdlIG5lZWQgdG8gbWFrZSBzdXJlIHdlIGNhbg0KPiA+IGZpbmQgdGhlIGNvcnJlY3QgY3B1
IG5vZGVzIGluIHRoZSBkZXZpY2UgdHJlZSBiYXNlZCBvbiB0aGUgZ2l2ZW4NCj4gPiBsb2dpY2Fs
IGNwdSBpbmRleCBmcm9tIHRoZSBjYWxsZXIuDQo+ID4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBIYWl5
aW5nIFdhbmcgPEhhaXlpbmcuV2FuZ0BmcmVlc2NhbGUuY29tPg0KPiA+IC0tLQ0KPiA+ICBkcml2
ZXJzL2lvbW11L2ZzbF9wYW11LmMgfCAgICAzICsrLQ0KPiA+ICAxIGZpbGVzIGNoYW5nZWQsIDIg
aW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkNCj4gPg0KPiA+IGRpZmYgLS1naXQgYS9kcml2
ZXJzL2lvbW11L2ZzbF9wYW11LmMgYi9kcml2ZXJzL2lvbW11L2ZzbF9wYW11LmMgaW5kZXgNCj4g
PiBjYmEwNDk4Li5hOWFiNTdiIDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMvaW9tbXUvZnNsX3Bh
bXUuYw0KPiA+ICsrKyBiL2RyaXZlcnMvaW9tbXUvZnNsX3BhbXUuYw0KPiA+IEBAIC01MzksNiAr
NTM5LDcgQEAgdTMyIGdldF9zdGFzaF9pZCh1MzIgc3Rhc2hfZGVzdF9oaW50LCB1MzIgdmNwdSkN
Cj4gDQo+IFNob3VsZCBwcm9iYWJseSBhbHNvIHMvdmNwdS9jcHUvZyBhcyB2Y3B1IG1ha2VzIG5v
IHNlbnNlIG91dHNpZGUgb2YNCj4gdmlydHVhbGl6YXRpb24gY29kZS4NCj4gDQo+ID4gIAl1MzIg
Y2FjaGVfbGV2ZWw7DQo+ID4gIAlpbnQgbGVuLCBmb3VuZCA9IDA7DQo+ID4gIAlpbnQgaTsNCj4g
PiArCXUzMiBjcHVpZCA9IGdldF9oYXJkX3NtcF9wcm9jZXNzb3JfaWQodmNwdSk7DQo+IA0KPiBz
L2NwdWlkL3BoeXNfY3B1LyBvciBzaW1pbGFyDQo+IA0KPiAtU2NvdHQNCj4gDQoNCg==
^ permalink raw reply
* Re: [PATCH 0/2] Add monaural audio support for fsl_ssi.c
From: Shawn Guo @ 2013-11-15 3:22 UTC (permalink / raw)
To: Nicolin Chen
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, lgirdwood, swarren, timur, rob.herring,
linux-kernel, broonie, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20131115025956.GA745@MrMyself>
On Fri, Nov 15, 2013 at 10:59:57AM +0800, Nicolin Chen wrote:
> Hi Shawn,
>
> On Fri, Nov 15, 2013 at 11:02:49AM +0800, Shawn Guo wrote:
> > On Thu, Nov 14, 2013 at 07:07:08PM +0800, Nicolin Chen wrote:
> > > This series of patches need to be applied into one single tree because
> > > the second patch depends on the first one. Without it, SSI would playback
> > > constant noise to the right channel when playback monaural audio files on
> > > i.MX6 Series board.
> >
> > Let me try to understand if the dependency is true.
> >
> > Saying I apply the DTS patch on IMX tree while Mark apply the fsl_ssi
> > patch on his tree, will there be any regression on either IMX tree or
> > Mark's tree? The monaural playback on imx6qdl never worked, so it's not
> > a regression. If there is no regression on either tree, there is no
> > dependency to maintain.
>
> It's fair enough to understand in this way. It looks like I misunderstood
> the dependency here.
>
> Do I need to resend them separately?
No, I will just pick up the DTS patch with some testing.
Shawn
^ permalink raw reply
* Re: [PATCH 0/2] Add monaural audio support for fsl_ssi.c
From: Nicolin Chen @ 2013-11-15 3:15 UTC (permalink / raw)
To: Shawn Guo
Cc: mark.rutland, devicetree, alsa-devel, linux, pawel.moll,
ijc+devicetree, lgirdwood, swarren, timur, rob.herring,
linux-kernel, broonie, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20131115032250.GD11014@S2101-09.ap.freescale.net>
On Fri, Nov 15, 2013 at 11:22:52AM +0800, Shawn Guo wrote:
> On Fri, Nov 15, 2013 at 10:59:57AM +0800, Nicolin Chen wrote:
> > Hi Shawn,
> >
> > On Fri, Nov 15, 2013 at 11:02:49AM +0800, Shawn Guo wrote:
> > > On Thu, Nov 14, 2013 at 07:07:08PM +0800, Nicolin Chen wrote:
> > > > This series of patches need to be applied into one single tree because
> > > > the second patch depends on the first one. Without it, SSI would playback
> > > > constant noise to the right channel when playback monaural audio files on
> > > > i.MX6 Series board.
> > >
> > > Let me try to understand if the dependency is true.
> > >
> > > Saying I apply the DTS patch on IMX tree while Mark apply the fsl_ssi
> > > patch on his tree, will there be any regression on either IMX tree or
> > > Mark's tree? The monaural playback on imx6qdl never worked, so it's not
> > > a regression. If there is no regression on either tree, there is no
> > > dependency to maintain.
> >
> > It's fair enough to understand in this way. It looks like I misunderstood
> > the dependency here.
> >
> > Do I need to resend them separately?
>
> No, I will just pick up the DTS patch with some testing.
>
> Shawn
Thank you.
Nicolin Chen
^ permalink raw reply
* [RFC PATCH] powerpc/powernv: infrastructure to read opal messages in generic format.
From: Mahesh J Salgaonkar @ 2013-11-15 4:11 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Opal now has a new messaging infrastructure to push the messages to
linux in a generic format for different type of messages using only one
event bit. The format of the opal message is as below:
struct opal_msg {
uint32_t msg_type;
uint32_t reserved;
uint64_t params[8];
};
This patch allows clients to subscribe for notification for specific
message type. It is upto the subscriber to decipher the messages who showed
interested in receiving specific message type.
The interface to subscribe for notification is:
int opal_message_notifier_register(enum OpalMessageType msg_type,
struct notifier_block *nb)
The notifier will fetch the opal message when available and notify the
subscriber with message type and the opal message. It is subscribers
responsibility to copy the message data before returning from notifier
callback.
I will post a seperate patch series for fsp memory handling which uses
this new messaging channel to pull fsp memory errors.
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 23 ++++++
arch/powerpc/platforms/powernv/opal-wrappers.S | 2 +
arch/powerpc/platforms/powernv/opal.c | 90 ++++++++++++++++++++++++
3 files changed, 114 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index c5cd728..3de7ac6 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -129,6 +129,8 @@ extern int opal_enter_rtas(struct rtas_args *args,
#define OPAL_LPC_READ 67
#define OPAL_LPC_WRITE 68
#define OPAL_RETURN_CPU 69
+#define OPAL_GET_MSG 80
+#define OPAL_CHECK_COMP 81
#ifndef __ASSEMBLY__
@@ -208,7 +210,16 @@ enum OpalPendingState {
OPAL_EVENT_ERROR_LOG = 0x40,
OPAL_EVENT_EPOW = 0x80,
OPAL_EVENT_LED_STATUS = 0x100,
- OPAL_EVENT_PCI_ERROR = 0x200
+ OPAL_EVENT_PCI_ERROR = 0x200,
+ OPAL_EVENT_PENDING_MSGS = 0x400,
+};
+
+enum OpalMessageType {
+ OPAL_MSG_ASYNC_COMP = 0,
+ OPAL_MSG_MEM_ERR,
+ OPAL_MSG_EPOW,
+ OPAL_MSG_SHUTDOWN,
+ OPAL_MSG_TYPE_MAX,
};
/* Machine check related definitions */
@@ -353,6 +364,12 @@ enum OpalLPCAddressType {
OPAL_LPC_FW = 2,
};
+struct opal_msg {
+ uint32_t msg_type;
+ uint32_t reserved;
+ uint64_t params[8];
+};
+
struct opal_machine_check_event {
enum OpalMCE_Version version:8; /* 0x00 */
uint8_t in_use; /* 0x01 */
@@ -656,6 +673,8 @@ int64_t opal_lpc_write(uint32_t chip_id, enum OpalLPCAddressType addr_type,
uint32_t addr, uint32_t data, uint32_t sz);
int64_t opal_lpc_read(uint32_t chip_id, enum OpalLPCAddressType addr_type,
uint32_t addr, uint32_t *data, uint32_t sz);
+int64_t opal_get_msg(uint64_t buffer, size_t size);
+int64_t opal_check_completion(uint64_t buffer, size_t size, uint64_t token);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname, int depth, void *data);
@@ -670,6 +689,8 @@ extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
int depth, void *data);
extern int opal_notifier_register(struct notifier_block *nb);
+extern int opal_message_notifier_register(enum OpalMessageType msg_type,
+ struct notifier_block *nb);
extern void opal_notifier_enable(void);
extern void opal_notifier_disable(void);
extern void opal_notifier_update_evt(uint64_t evt_mask, uint64_t evt_val);
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 8f38445..a082d42 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -116,3 +116,5 @@ OPAL_CALL(opal_xscom_write, OPAL_XSCOM_WRITE);
OPAL_CALL(opal_lpc_read, OPAL_LPC_READ);
OPAL_CALL(opal_lpc_write, OPAL_LPC_WRITE);
OPAL_CALL(opal_return_cpu, OPAL_RETURN_CPU);
+OPAL_CALL(opal_get_msg, OPAL_GET_MSG);
+OPAL_CALL(opal_check_completion, OPAL_CHECK_COMP);
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index 2911abe..d3759f7 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -33,6 +33,7 @@ extern u64 opal_mc_secondary_handler[];
static unsigned int *opal_irqs;
static unsigned int opal_irq_count;
static ATOMIC_NOTIFIER_HEAD(opal_notifier_head);
+static struct atomic_notifier_head opal_msg_notifier_head[OPAL_MSG_TYPE_MAX];
static DEFINE_SPINLOCK(opal_notifier_lock);
static uint64_t last_notified_mask = 0x0ul;
static atomic_t opal_notifier_hold = ATOMIC_INIT(0);
@@ -162,6 +163,95 @@ void opal_notifier_disable(void)
atomic_set(&opal_notifier_hold, 1);
}
+/*
+ * Opal message notifier based on message type. Allow subscribers to get
+ * notified for specific messgae type.
+ */
+int opal_message_notifier_register(enum OpalMessageType msg_type,
+ struct notifier_block *nb)
+{
+ if (!nb) {
+ pr_warning("%s: Invalid argument (%p)\n",
+ __func__, nb);
+ return -EINVAL;
+ }
+ if (msg_type > OPAL_MSG_TYPE_MAX) {
+ pr_warning("%s: Invalid message type argument (%d)\n",
+ __func__, msg_type);
+ return -EINVAL;
+ }
+ return atomic_notifier_chain_register(
+ &opal_msg_notifier_head[msg_type], nb);
+}
+
+static void opal_message_do_notify(uint32_t msg_type, void *msg)
+{
+ /* notify subscribers */
+ atomic_notifier_call_chain(&opal_msg_notifier_head[msg_type],
+ msg_type, msg);
+}
+
+static void opal_message_handle_event(void)
+{
+ s64 ret;
+ /*
+ * TODO: pre-allocate a message buffer depending on opal-msg-size
+ * value in /proc/device-tree.
+ */
+ static struct opal_msg msg;
+
+ ret = opal_get_msg(__pa(&msg), sizeof(msg));
+ /* No opal message pending. */
+ if (ret == OPAL_RESOURCE)
+ return;
+
+ /* check for errors. */
+ if (ret) {
+ pr_warning("%s: Failed to retrive opal message, err=%lld\n",
+ __func__, ret);
+ return;
+ }
+
+ /* Sanity check */
+ if (msg.msg_type > OPAL_MSG_TYPE_MAX) {
+ pr_warning("%s: Unknown message type: %u\n",
+ __func__, msg.msg_type);
+ return;
+ }
+ opal_message_do_notify(msg.msg_type, (void *)&msg);
+}
+
+static int opal_message_notify(struct notifier_block *nb,
+ unsigned long events, void *change)
+{
+ if (events & OPAL_EVENT_PENDING_MSGS)
+ opal_message_handle_event();
+ return 0;
+}
+
+static struct notifier_block opal_message_nb = {
+ .notifier_call = opal_message_notify,
+ .next = NULL,
+ .priority = 0,
+};
+
+static int __init opal_message_init(void)
+{
+ int ret, i;
+
+ for (i = 0; i < OPAL_MSG_TYPE_MAX; i++)
+ ATOMIC_INIT_NOTIFIER_HEAD(&opal_msg_notifier_head[i]);
+
+ ret = opal_notifier_register(&opal_message_nb);
+ if (ret) {
+ pr_err("%s: Can't register OPAL event notifier (%d)\n",
+ __func__, ret);
+ return ret;
+ }
+ return 0;
+}
+early_initcall(opal_message_init);
+
int opal_get_chars(uint32_t vtermno, char *buf, int count)
{
s64 len, rc;
^ permalink raw reply related
* [PATCH 0/2] powerpc/powernv: Plumb fsp memory errors to memory poison infrastructure.
From: Mahesh J Salgaonkar @ 2013-11-15 4:20 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Hi,
Please find the patch set that implements FSP memory error handling and
plumbs then into memory poison infrastructure.
Patch 1 enables the generic memory hwpoisoning infrastructure for ppc64.
Patch 2 reads the memory errors reported from opal layer and plumbs them
into memory poison infrastructure.
This patch uses new messaging channel infrastructure (proposed through a
separate patch at
https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-November/113331.html)
to pull the fsp memory errors to linux.
Thanks,
-Mahesh.
---
Mahesh Salgaonkar (2):
powerpc/powernv: Add config option for hwpoisoning.
powerpc/powernv: Get FSP memory errors and plumb into memory poison infrastructure.
arch/powerpc/Kconfig | 6 +
arch/powerpc/include/asm/opal.h | 52 +++++++
arch/powerpc/platforms/powernv/Makefile | 1
.../powerpc/platforms/powernv/opal-memory-errors.c | 146 ++++++++++++++++++++
4 files changed, 205 insertions(+)
create mode 100644 arch/powerpc/platforms/powernv/opal-memory-errors.c
--
-Mahesh
^ permalink raw reply
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