* [PATCH 15/21] powerpc: drop unused Kconfig symbols
From: Paul Bolle @ 2011-10-14 12:30 UTC (permalink / raw)
To: Josh Boyer, Matt Porter; +Cc: linuxppc-dev, linux-kernel
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
arch/powerpc/Kconfig | 22 ----------------------
arch/powerpc/platforms/40x/Kconfig | 5 -----
arch/powerpc/platforms/Kconfig.cputype | 8 --------
arch/powerpc/platforms/embedded6xx/Kconfig | 4 ----
arch/powerpc/platforms/prep/Kconfig | 9 ---------
arch/powerpc/platforms/wsp/Kconfig | 5 -----
6 files changed, 0 insertions(+), 53 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 6926b61..6887d80 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -379,10 +379,6 @@ config PHYP_DUMP
If unsure, say "N"
-config PPCBUG_NVRAM
- bool "Enable reading PPCBUG NVRAM during boot" if PPLUS || LOPEC
- default y if PPC_PREP
-
config IRQ_ALL_CPUS
bool "Distribute interrupts on all CPUs by default"
depends on SMP && !MV64360
@@ -744,24 +740,6 @@ config 8260_PCI9
depends on PCI_8260 && !8272
default y
-choice
- prompt "IDMA channel for PCI 9 workaround"
- depends on 8260_PCI9
-
-config 8260_PCI9_IDMA1
- bool "IDMA1"
-
-config 8260_PCI9_IDMA2
- bool "IDMA2"
-
-config 8260_PCI9_IDMA3
- bool "IDMA3"
-
-config 8260_PCI9_IDMA4
- bool "IDMA4"
-
-endchoice
-
source "drivers/pci/pcie/Kconfig"
source "drivers/pci/Kconfig"
diff --git a/arch/powerpc/platforms/40x/Kconfig b/arch/powerpc/platforms/40x/Kconfig
index d733d7c..4bd3a27 100644
--- a/arch/powerpc/platforms/40x/Kconfig
+++ b/arch/powerpc/platforms/40x/Kconfig
@@ -115,11 +115,6 @@ config PPC40x_SIMPLE
help
This option enables the simple PowerPC 40x platform support.
-# 40x specific CPU modules, selected based on the board above.
-config NP405H
- bool
- #depends on ASH
-
# OAK doesn't exist but wanted to keep this around for any future 403GCX boards
config 403GCX
bool
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index e06e395..f16f997 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -282,14 +282,6 @@ config PPC_MMU_NOHASH
def_bool y
depends on !PPC_STD_MMU
-config PPC_MMU_NOHASH_32
- def_bool y
- depends on PPC_MMU_NOHASH && PPC32
-
-config PPC_MMU_NOHASH_64
- def_bool y
- depends on PPC_MMU_NOHASH && PPC64
-
config PPC_BOOK3E_MMU
def_bool y
depends on FSL_BOOKE || PPC_BOOK3E
diff --git a/arch/powerpc/platforms/embedded6xx/Kconfig b/arch/powerpc/platforms/embedded6xx/Kconfig
index 524d971..5a8f50a 100644
--- a/arch/powerpc/platforms/embedded6xx/Kconfig
+++ b/arch/powerpc/platforms/embedded6xx/Kconfig
@@ -87,10 +87,6 @@ config MV64X60
config MPC10X_OPENPIC
bool
-config MPC10X_STORE_GATHERING
- bool "Enable MPC10x store gathering"
- depends on MPC10X_BRIDGE
-
config GAMECUBE_COMMON
bool
diff --git a/arch/powerpc/platforms/prep/Kconfig b/arch/powerpc/platforms/prep/Kconfig
index f0536c7..1547f66 100644
--- a/arch/powerpc/platforms/prep/Kconfig
+++ b/arch/powerpc/platforms/prep/Kconfig
@@ -21,12 +21,3 @@ config PREP_RESIDUAL
or pass the 'noresidual' option to the kernel.
If you are running a PReP system, say Y here, otherwise say N.
-
-config PROC_PREPRESIDUAL
- bool "Support for reading of PReP Residual Data in /proc"
- depends on PREP_RESIDUAL && PROC_FS
- help
- Enabling this option will create a /proc/residual file which allows
- you to get at the residual data on PReP systems. You will need a tool
- (lsresidual) to parse it. If you aren't on a PReP system, you don't
- want this.
diff --git a/arch/powerpc/platforms/wsp/Kconfig b/arch/powerpc/platforms/wsp/Kconfig
index c3c48eb..375f01e 100644
--- a/arch/powerpc/platforms/wsp/Kconfig
+++ b/arch/powerpc/platforms/wsp/Kconfig
@@ -21,8 +21,3 @@ endmenu
config PPC_A2_DD2
bool "Support for DD2 based A2/WSP systems"
depends on PPC_A2
-
-config WORKAROUND_ERRATUM_463
- depends on PPC_A2_DD2
- bool "Workaround erratum 463"
- default y
--
1.7.4.4
^ permalink raw reply related
* RE: I2c-cpm driver not working
From: smitha.vanga @ 2011-10-14 10:02 UTC (permalink / raw)
To: R65777, B07421; +Cc: linuxppc-dev
In-Reply-To: <B8D6CA50DACE9E4AAADE9A4D56FBAAE622DD7D@039-SN1MPN1-004.039d.mgd.msft.net>
Hi ,
I see that the i2c_master_send works but when I do a i2c_master_recv returns=
with a error code -121.
What should be the i2c-base address be configured for the i2c-cpm driver for=
mpc9247 . Also
When I pass the interrupt for this driver as 1 , I see the registered interr=
upt number as 10 in /proc/interrupts why is it like this?
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email.
www.wipro.com
^ permalink raw reply
* [PATCH] mtd: m25p80: don't probe device which has status of 'disabled'
From: Shaohui Xie @ 2011-10-14 7:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-mtd, Shaohui Xie
On some platforms such as P3060QDS, has multiple spi flashes, but they are
not available at same time, so if their status is 'disabled', which is set
by u-boot, will not be probed.
Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
---
Disabled nodes should automatically not be probed. But I found this is only
true for spi node, for the flash nodes which embedded in spi node, still got
probed even it has a status of 'disabled'.
drivers/mtd/devices/m25p80.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index 4e20c4d..30d61d5 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -30,6 +30,7 @@
#include <linux/mtd/cfi.h>
#include <linux/mtd/mtd.h>
#include <linux/mtd/partitions.h>
+#include <linux/of_platform.h>
#include <linux/spi/spi.h>
#include <linux/spi/flash.h>
@@ -829,6 +830,11 @@ static int __devinit m25p_probe(struct spi_device *spi)
struct mtd_partition *parts = NULL;
int nr_parts = 0;
+#ifdef CONFIG_MTD_OF_PARTS
+ if (!of_device_is_available(spi->dev.of_node))
+ return -ENODEV;
+#endif
+
/* Platform data helps sort out which chip type we have, as
* well as how this board partitions it. If we don't have
* a chip ID, try the JEDEC id commands; they'll work for most
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] mtd: m25p80: add EON flash EN25Q32B into spi flash id table
From: Artem Bityutskiy @ 2011-10-14 8:37 UTC (permalink / raw)
To: Shaohui Xie; +Cc: linux-mtd, linuxppc-dev
In-Reply-To: <1317366518-11403-1-git-send-email-Shaohui.Xie@freescale.com>
On Fri, 2011-09-30 at 15:08 +0800, Shaohui Xie wrote:
> Add support for EON spi flash EN25Q32B, which is not listed in id table,
> need to add it in the id table to support the EON flash.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Pushed to l2-mtd-2.6.git, thanks!
--
Best Regards,
Artem Bityutskiy
^ permalink raw reply
* [PATCH] drivers/virt: add ioctl for 32-bit compat on 64-bit to fsl-hv-manager
From: Kumar Gala @ 2011-10-14 7:56 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mihai Caraman, linux-kernel
From: Mihai Caraman <mihai.caraman@freescale.com>
Add ioctl to Freescale hypervisor management driver for 32-bit user-space
applications running on 64-bit guests.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
Acked-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/virt/fsl_hypervisor.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
index 3d91621..4939e0c 100644
--- a/drivers/virt/fsl_hypervisor.c
+++ b/drivers/virt/fsl_hypervisor.c
@@ -706,6 +706,7 @@ static const struct file_operations fsl_hv_fops = {
.poll = fsl_hv_poll,
.read = fsl_hv_read,
.unlocked_ioctl = fsl_hv_ioctl,
+ .compat_ioctl = fsl_hv_ioctl,
};
static struct miscdevice fsl_hv_misc_dev = {
--
1.7.3.4
^ permalink raw reply related
* [PATCH] powerpc/85xx: Setup secondary cores PIR with hard SMP id
From: Kumar Gala @ 2011-10-14 7:52 UTC (permalink / raw)
To: linuxppc-dev
Normally logical and hard cpu ID are the same, however in same cases like
on the P3060 they may differ. Where the logical is 0..5, the hard id
goes 0,1,4..7. This can causes issues for places we utilize PIR to index
into array like in debug exception handlers for finding the exception
stack.
Move to setting up PIR with hard_smp_processor_id fixes the issue.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/smp.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index d6e4746..190d111 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -48,10 +48,11 @@ smp_85xx_kick_cpu(int nr)
const u64 *cpu_rel_addr;
__iomem u32 *bptr_vaddr;
struct device_node *np;
- int n = 0;
+ int n = 0, hw_cpu = get_hard_smp_processor_id(nr);
int ioremappable;
- WARN_ON (nr < 0 || nr >= NR_CPUS);
+ WARN_ON(nr < 0 || nr >= NR_CPUS);
+ WARN_ON(hw_cpu < 0 || hw_cpu >= NR_CPUS);
pr_debug("smp_85xx_kick_cpu: kick CPU #%d\n", nr);
@@ -79,7 +80,7 @@ smp_85xx_kick_cpu(int nr)
local_irq_save(flags);
- out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
+ out_be32(bptr_vaddr + BOOT_ENTRY_PIR, hw_cpu);
#ifdef CONFIG_PPC32
out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
@@ -88,7 +89,7 @@ smp_85xx_kick_cpu(int nr)
(ulong)(bptr_vaddr + SIZE_BOOT_ENTRY));
/* Wait a bit for the CPU to ack. */
- while ((__secondary_hold_acknowledge != nr) && (++n < 1000))
+ while ((__secondary_hold_acknowledge != hw_cpu) && (++n < 1000))
mdelay(1);
#else
smp_generic_kick_cpu(nr);
--
1.7.3.4
^ permalink raw reply related
* Re: How to handle cache when I allocate phys memory?
From: Benjamin Herrenschmidt @ 2011-10-14 7:39 UTC (permalink / raw)
To: Ayman El-Khashab; +Cc: linuxppc-dev
In-Reply-To: <20111012210816.GA17878@crust.elkhashab.com>
On Wed, 2011-10-12 at 16:08 -0500, Ayman El-Khashab wrote:
> I'm using the 460sx (440 core) so no snooping here. What
> I've done is reserved the top of memory for my driver. My
> driver can read/write the memory and I can mmap it just
> fine. The problem is I want to enable caching on the mmap
> for performance but I don't know / can't figure out how to
> tell the kernel to sync the cache after it gets dma data
> from the device or after i put data into it from user space.
> I know how to do it from regular devices, but not when I've
> allocated the physical memory myself. I suppose what I am
> looking for is something akin to dma_sync_single cpu/device.
>
> In my device driver, I am allocating the memory like this,
> in this case the buffer is about 512MB.
>
> vma->vm_flags |= VM_LOCKED | VM_RESERVED;
>
> /* map the physical area into one buffer */
> rc = remap_pfn_range(vma, vma->vm_start,
> (PHYS_MEM_ADDR)>>PAGE_SHIFT,
> len, vma->vm_page_prot);
>
> Is this going to give me the best performance, or is there
> something more I can do?
>
> Failing that, what is the best way to do this (i need a very
> large contiguous buffer). it runs in batch mode, so it
> DMAs, stops, cpu reads, cpu writes, repeat ...
Did you try looking at what the dma_* functions do under the hood and
call it directly (or reproducing it) ?
Basically it boils down to using dcbf instructions to flush dirty data
or dcbi to invalidate cache lines.
Cheers,
Ben.
^ permalink raw reply
* RE: I2c-cpm drievr not working
From: Bhushan Bharat-R65777 @ 2011-10-14 5:42 UTC (permalink / raw)
To: smitha.vanga@wipro.com, Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <40631E9A2581F14BA60888C87A76A1FE015B09@HYD-MKD-MBX4.wipro.com>
> -----Original Message-----
> From: linuxppc-dev-bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.or=
g
> [mailto:linuxppc-dev-
> bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf Of
> smitha.vanga@wipro.com
> Sent: Friday, October 14, 2011 9:45 AM
> To: Wood Scott-B07421
> Cc: linuxppc-dev@lists.ozlabs.org
> Subject: I2c-cpm drievr not working
>=20
>=20
> Hi Scott,
>=20
> I am using the i2c-cpm driver to read and write to a LM75 sensor. The int
> i2c_master_send(struct i2c_client *client,const char *buf ,int count)
> function is not successful.
> Could you let me know what may be the issue. Below are the traces.
>=20
> DS75_DRIVER : Open
> DS75_DRIVER : Device Open Successful!
> DS75_DRIVER : ioctl TEMP_READ cmd 1
> In i2c_master_send enter-------
> In i2c_master_send enter [2]-------
> In i2c_master_send msg.addr=3Dc031
> In i2c_master_send 1 client->addr =3D0
> In i2c_master_send 2
> In i2c_master_send 3
> In i2c_master_send 4
> --- enter i2c_transfer
I am a bit confused that i2c_transfer() is called after i2c_master_send is =
entered 4 times. Should not this be called every time ?
> i2c_transfer_entry
> *********** cpm_i2c_xfer
> ***********cpm_i2c_parse_message
> ***********cpm_i2c_check_message
> *********** else
> rv =3D1
> In i2c_master_send 5
> i2c_master_recv client.addr=3D0
> --- enter i2c_transfer
This time it is called on first shot.
Do you think you need to define I2C_CHIP_ERRATA ?
Thanks
-Bharat
> i2c_transfer_entry
> *********** cpm_i2c_xfer
> ***********cpm_i2c_parse_message
> i2c_adapter i2c-0: I2C transfer: timeout
> *********** cpm_i2c_xfer out_err
> ***********cpm_i2c_force_close
> rv =3Dffffff87
> DS75_DRIVER : Error reading from I2C
>=20
> Regards,
> Smitha
> Please do not print this email unless it is absolutely necessary.
>=20
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s)
> and may contain proprietary, confidential or privileged information. If
> you are not the intended recipient, you should not disseminate,
> distribute or copy this e-mail. Please notify the sender immediately and
> destroy all copies of this message and any attachments.
>=20
> WARNING: Computer viruses can be transmitted via email. The recipient
> should check this email and any attachments for the presence of viruses.
> The company accepts no liability for any damage caused by any virus
> transmitted by this email.
>=20
> www.wipro.com
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* I2c-cpm drievr not working
From: smitha.vanga @ 2011-10-14 4:14 UTC (permalink / raw)
To: scottwood; +Cc: linuxppc-dev
In-Reply-To: <4E8C9741.9010401@freescale.com>
Hi Scott,
I am using the i2c-cpm driver to read and write to a LM75 sensor. The
int i2c_master_send(struct i2c_client *client,const char *buf ,int count) fu=
nction is not successful.
Could you let me know what may be the issue. Below are the traces.
DS75_DRIVER : Open
DS75_DRIVER : Device Open Successful!
DS75_DRIVER : ioctl TEMP_READ cmd 1
In i2c_master_send enter-------
In i2c_master_send enter [2]-------
In i2c_master_send msg.addr=3Dc031
In i2c_master_send 1 client->addr =3D0
In i2c_master_send 2
In i2c_master_send 3
In i2c_master_send 4
--- enter i2c_transfer
i2c_transfer_entry
*********** cpm_i2c_xfer
***********cpm_i2c_parse_message
***********cpm_i2c_check_message
*********** else
rv =3D1
In i2c_master_send 5
i2c_master_recv client.addr=3D0
--- enter i2c_transfer
i2c_transfer_entry
*********** cpm_i2c_xfer
***********cpm_i2c_parse_message
i2c_adapter i2c-0: I2C transfer: timeout
*********** cpm_i2c_xfer out_err
***********cpm_i2c_force_close
rv =3Dffffff87
DS75_DRIVER : Error reading from I2C
Regards,
Smitha
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to=
this message are intended for the exclusive use of the addressee(s) and may=
contain proprietary, confidential or privileged information. If you are not=
the intended recipient, you should not disseminate, distribute or copy this=
e-mail. Please notify the sender immediately and destroy all copies of this=
message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should=
check this email and any attachments for the presence of viruses. The compa=
ny accepts no liability for any damage caused by any virus transmitted by th=
is email.
www.wipro.com
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Timur Tabi @ 2011-10-13 15:59 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20111013175026.1479c674@wker>
Anatolij Gustschin wrote:
> there is no 32bit address map DTS file for P1022DS in the mainline
> tree. A proper patch should then also add appropriate 32bit address
> map DTS file. I'm not in the position to do it currently since it would
> require testing, I do not have this board to test patches for it.
The defconfig already enables CONFIG_PHYS_64BIT for the P1022DS and all other
85xx parts. If you look at the Kconfig, you'll see that most boards don't
enable it. So by default, everything is 64-bit capable.
Adding the Kconfig option will *prevent* anyone from creating a 32-bit kernel.
This is my problem with the patch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Anatolij Gustschin @ 2011-10-13 15:52 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4E970780.7000100@freescale.com>
On Thu, 13 Oct 2011 10:45:04 -0500
Timur Tabi <timur@freescale.com> wrote:
> Kumar Gala wrote:
> > I think this 25% number is bogus. There are cases where it also improves performance.
>
> I don't think we ever ship a P1022 system with more than 2GB of DDR, so I can't
> see how performance is ever improved.
>
> I will post a patch that removes the Kconfig option, but I don't understand why
> you couldn't do that when you applied the patch.
please also post a patch providing a working 32bit address
map DTS for this board, then.
Anatolij
^ permalink raw reply
* [PATCH] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-13 15:50 UTC (permalink / raw)
To: hjk; +Cc: linuxppc-dev, gregkh, Kai Jiang, linux-kernel
From: Kai Jiang <Kai.Jiang@freescale.com>
To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
extend the width of 'addr' in struct uio_mem. Numerous platforms like
embedded PPC, ARM, and X86 have support for systems with larger physical
address than logical.
Since 'addr' may contain a physical, logical, or virtual address the
easiest solution is to just change the type to 'phys_addr_t' which
should always be greater than or equal to the sizeof(void *) such that
it can properly hold any of the address types.
For physical address we can support up to a 44-bit physical address on a
typical 32-bit system as we utilize remap_pfn_range() for the mapping of
the memory region and pfn's are represnted by shifting the address by
the page size (typically 4k).
Signed-off-by: Kai Jiang <Kai.Jiang@freescale.com>
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
v3:
* Updated commit message to be correct w/regards to code
* Updated comment about addr field in uio_mem
v2:
* Use phys_addr_t instead of 'unsigned long long'
* Updated DocBook detail in uio-howto.tmpl
Documentation/DocBook/uio-howto.tmpl | 2 +-
drivers/uio/uio.c | 8 ++++----
include/linux/uio_driver.h | 7 +++++--
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index 7c4b514d..54883de 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -529,7 +529,7 @@ memory (e.g. allocated with <function>kmalloc()</function>). There's also
</para></listitem>
<listitem><para>
-<varname>unsigned long addr</varname>: Required if the mapping is used.
+<varname>phys_addr_t addr</varname>: Required if the mapping is used.
Fill in the address of your memory block. This address is the one that
appears in sysfs.
</para></listitem>
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index 88f4444..43b7096 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -69,7 +69,7 @@ static ssize_t map_name_show(struct uio_mem *mem, char *buf)
static ssize_t map_addr_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr);
+ return sprintf(buf, "0x%llx\n", (unsigned long long)mem->addr);
}
static ssize_t map_size_show(struct uio_mem *mem, char *buf)
@@ -79,7 +79,7 @@ static ssize_t map_size_show(struct uio_mem *mem, char *buf)
static ssize_t map_offset_show(struct uio_mem *mem, char *buf)
{
- return sprintf(buf, "0x%lx\n", mem->addr & ~PAGE_MASK);
+ return sprintf(buf, "0x%llx\n", (unsigned long long)mem->addr & ~PAGE_MASK);
}
struct map_sysfs_entry {
@@ -634,8 +634,8 @@ static int uio_vma_fault(struct vm_area_struct *vma, struct vm_fault *vmf)
if (idev->info->mem[mi].memtype == UIO_MEM_LOGICAL)
page = virt_to_page(idev->info->mem[mi].addr + offset);
else
- page = vmalloc_to_page((void *)idev->info->mem[mi].addr
- + offset);
+ page = vmalloc_to_page((void *)(unsigned long)
+ idev->info->mem[mi].addr + offset);
get_page(page);
vmf->page = page;
return 0;
diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h
index 4c618cd..ad16aa9 100644
--- a/include/linux/uio_driver.h
+++ b/include/linux/uio_driver.h
@@ -23,7 +23,10 @@ struct uio_map;
/**
* struct uio_mem - description of a UIO memory region
* @name: name of the memory region for identification
- * @addr: address of the device's memory
+ * @addr: address of the device's memory (phys_addr is used since
+ * addr can be logical, virtual, or physical & phys_addr_t
+ * should always be large enough to handle any of the
+ * address types)
* @size: size of IO
* @memtype: type of memory addr points to
* @internal_addr: ioremap-ped version of addr, for driver internal use
@@ -32,7 +35,7 @@ struct uio_map;
*/
struct uio_mem {
const char *name;
- unsigned long addr;
+ phys_addr_t addr;
unsigned long size;
int memtype;
void __iomem *internal_addr;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Anatolij Gustschin @ 2011-10-13 15:50 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4E970528.8080908@freescale.com>
On Thu, 13 Oct 2011 10:35:04 -0500
Timur Tabi <timur@freescale.com> wrote:
> Kumar Gala wrote:
> >> > Why did you apply this patch? Both Scott and I rejected it.
>
> > Because its fixing a real issue. If we want to remove PHYS_64BIT support or make it optional for the board feel free to send another patch.
>
> Ok, so if someone posts a patch that works but does things the wrong way, and
> that patch gets rejected during reviews, but the submitter doesn't post a
> follow-up patch that does things the right way, you're going to apply the first
> patch anyway?
there is no 32bit address map DTS file for P1022DS in the mainline
tree. A proper patch should then also add appropriate 32bit address
map DTS file. I'm not in the position to do it currently since it would
require testing, I do not have this board to test patches for it.
Anatolij
^ permalink raw reply
* Re: [PATCH][v2] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-13 15:50 UTC (permalink / raw)
To: David Laight
Cc: gregkh, linux-kernel, linuxppc-dev, hjk, Jiang Kai-B18973,
Timur Tabi
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AE7E@saturn3.aculab.com>
On Oct 13, 2011, at 10:37 AM, David Laight wrote:
>
>> Kumar Gala wrote:
>>>>>>> + phys_addr_t addr;
>>>>>
>>>>> Please add a comment here saying:
>>>>>
>>>>> 1) That 'addr' can be a virtual or physical address
>>> The code and everything else makes that clear
>>
>> I'm sorry, but I have to strongly disagree here. It is *NOT*
>> clear that a variable of type 'phys_addr_t' can hold something
>> that is not a physical address.
>
> Since there is a discriminating field, could a union be used?
> At a guess the type of the address is constrained between
> produces and consumer??
Uugh.
I'll add a comment to uio_mem.
- k
^ permalink raw reply
* Re: [PATCH 0/3] 8xx: Large page(8MB) support for 2.4
From: Dan Malek @ 2011-10-13 15:48 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev, Willy Tarreau
In-Reply-To: <OFF1B869AD.14EDDF6F-ONC1257928.004AA88D-C1257928.004CF976@transmode.se>
On Oct 13, 2011, at 7:00 AM, Joakim Tjernlund wrote:
> ehhm, do the fun stuff first? :)
Need to pay the bills, first :-)
Thanks for the other information.
-- Dan
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Timur Tabi @ 2011-10-13 15:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: Anatolij Gustschin, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <E8940641-D5F9-4ADE-8892-387BB221AD71@kernel.crashing.org>
Kumar Gala wrote:
> I think this 25% number is bogus. There are cases where it also improves performance.
I don't think we ever ship a P1022 system with more than 2GB of DDR, so I can't
see how performance is ever improved.
I will post a patch that removes the Kconfig option, but I don't understand why
you couldn't do that when you applied the patch.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* RE: [PATCH][v2] uio: Support 36-bit physical addresses on 32-bit systems
From: David Laight @ 2011-10-13 15:37 UTC (permalink / raw)
To: Timur Tabi, Kumar Gala
Cc: linuxppc-dev, hjk, Jiang Kai-B18973, gregkh, linux-kernel
In-Reply-To: <4E9704F9.1090103@freescale.com>
=20
> Kumar Gala wrote:
> >>> >> + phys_addr_t addr;
> >> >=20
> >> > Please add a comment here saying:
> >> >=20
> >> > 1) That 'addr' can be a virtual or physical address
> > The code and everything else makes that clear
>=20
> I'm sorry, but I have to strongly disagree here. It is *NOT*=20
> clear that a variable of type 'phys_addr_t' can hold something
> that is not a physical address.
Since there is a discriminating field, could a union be used?
At a guess the type of the address is constrained between
produces and consumer??
David
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Kumar Gala @ 2011-10-13 15:41 UTC (permalink / raw)
To: Timur Tabi; +Cc: Anatolij Gustschin, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4E970528.8080908@freescale.com>
On Oct 13, 2011, at 10:35 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>>>> Why did you apply this patch? Both Scott and I rejected it.
>=20
>> Because its fixing a real issue. If we want to remove PHYS_64BIT =
support or make it optional for the board feel free to send another =
patch.
>=20
> Ok, so if someone posts a patch that works but does things the wrong =
way, and
> that patch gets rejected during reviews, but the submitter doesn't =
post a
> follow-up patch that does things the right way, you're going to apply =
the first
> patch anyway?
Leaving the code 'broken' I consider worse than slightly improving the =
situation which the patch does. The original patch for this board port =
introduced it with CONFIG_PHYS_64BIT set, thus I think it reasonable to =
take a patch that fixed an issue w/o anyone else putting out a patch.
If you really don't want it selected by default send me a patch to =
remove it and I'll apply. That is far more productive than this =
discussion.
> What about the BSP team's contention that enabling 64-bit support in =
the kernel
> can drop performance by up to 25% in some situations? We talked about =
that on
> an internal mailing list several months ago.
I think this 25% number is bogus. There are cases where it also =
improves performance.
- k=
^ permalink raw reply
* Re: [PATCH][v2] uio: Support 36-bit physical addresses on 32-bit systems
From: Timur Tabi @ 2011-10-13 15:41 UTC (permalink / raw)
To: David Laight; +Cc: gregkh, linux-kernel, linuxppc-dev, hjk, Jiang Kai-B18973
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AE7E@saturn3.aculab.com>
David Laight wrote:
> Since there is a discriminating field, could a union be used?
> At a guess the type of the address is constrained between
> produces and consumer??
I don't think we need to complicate the code by changing that variable into a
union. I just a want a short comment added to the structure definition. I
don't think that's asking a lot.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Timur Tabi @ 2011-10-13 15:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: Anatolij Gustschin, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6F5815DD-DBF0-4155-94CE-FEDC2C9802E1@kernel.crashing.org>
Kumar Gala wrote:
>> > Why did you apply this patch? Both Scott and I rejected it.
> Because its fixing a real issue. If we want to remove PHYS_64BIT support or make it optional for the board feel free to send another patch.
Ok, so if someone posts a patch that works but does things the wrong way, and
that patch gets rejected during reviews, but the submitter doesn't post a
follow-up patch that does things the right way, you're going to apply the first
patch anyway?
What about the BSP team's contention that enabling 64-bit support in the kernel
can drop performance by up to 25% in some situations? We talked about that on
an internal mailing list several months ago.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH][v2] uio: Support 36-bit physical addresses on 32-bit systems
From: Timur Tabi @ 2011-10-13 15:34 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev@ozlabs.org, hjk@hansjkoch.de, gregkh@suse.de,
linux-kernel@vger.kernel.org, Jiang Kai-B18973
In-Reply-To: <9BD33578-CD8E-4784-AC6A-ADE4614E0FC1@kernel.crashing.org>
Kumar Gala wrote:
>>> >> + phys_addr_t addr;
>> >
>> > Please add a comment here saying:
>> >
>> > 1) That 'addr' can be a virtual or physical address
> The code and everything else makes that clear
I'm sorry, but I have to strongly disagree here. It is *NOT* clear that a
variable of type 'phys_addr_t' can hold something that is not a physical address.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH][v2] uio: Support 36-bit physical addresses on 32-bit systems
From: Kumar Gala @ 2011-10-13 15:32 UTC (permalink / raw)
To: Tabi Timur-B04825
Cc: linuxppc-dev@ozlabs.org, hjk@hansjkoch.de, gregkh@suse.de,
linux-kernel@vger.kernel.org, Jiang Kai-B18973
In-Reply-To: <CAOZdJXWd_u_EWXNhh3-t258+Y8mx=JuJhU93CeZfaocPZvhOFA@mail.gmail.com>
On Oct 13, 2011, at 9:37 AM, Tabi Timur-B04825 wrote:
> On Wed, Oct 12, 2011 at 3:57 PM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>> From: Kai Jiang <Kai.Jiang@freescale.com>
>>=20
>> To support >32-bit physical addresses for UIO_MEM_PHYS type we need =
to
>> extend the width of 'addr' in struct uio_mem. Numerous platforms =
like
>> embedded PPC, ARM, and X86 have support for systems with larger =
physical
>> address than logical.
>>=20
>> Since 'addr' may contain a physical, logical, or virtual address the
>> easiest solution is to just change the type to 'unsigned long long'
>> regardless of which type is utilized.
>=20
> You forgot to update this description.
will fix and update commit message
>=20
>> struct uio_mem {
>> const char *name;
>> - unsigned long addr;
>> + phys_addr_t addr;
>=20
> Please add a comment here saying:
>=20
> 1) That 'addr' can be a virtual or physical address
The code and everything else makes that clear
> 2) That the kernel guarantees that sizeof(phys_addr_t) >=3D =
sizeof(void
> *), so it's safe to use phys_addr_t for a virtual pointer.
The commit message will cover that so I don't plan on add it.
- k=
^ permalink raw reply
* Re: [PATCH] powerpc/85xx: fix PHYS_64BIT selection for P1022DS
From: Kumar Gala @ 2011-10-13 15:31 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: Anatolij Gustschin, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CAOZdJXUWiatadSCmCAvMRrVjVKCJb0xo+XGsF=Rz5-Smp08tMA@mail.gmail.com>
On Oct 13, 2011, at 9:14 AM, Tabi Timur-B04825 wrote:
> On Tue, Oct 11, 2011 at 11:53 PM, Kumar Gala =
<galak@kernel.crashing.org> wrote:
>>=20
>> On Sep 23, 2011, at 2:32 PM, Anatolij Gustschin wrote:
>>=20
>>> Remove wrong CONFIG_ prefix in Kconfig file.
>>>=20
>>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>>> ---
>>> arch/powerpc/platforms/85xx/Kconfig | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>=20
>> applied
>=20
> Why did you apply this patch? Both Scott and I rejected it.
Because its fixing a real issue. If we want to remove PHYS_64BIT =
support or make it optional for the board feel free to send another =
patch.
- k=
^ permalink raw reply
* [PATCH] powerpc/85xx: Setup secondary cores PIR with hard SMP id
From: Kumar Gala @ 2011-10-13 15:20 UTC (permalink / raw)
To: linuxppc-dev
Normally logical and hard cpu ID are the same, however in same cases like
on the P3060 they may differ. Where the logical is 0..5, the hard id
goes 0,1,4..7. This can causes issues for places we utilize PIR to index
into array like in debug exception handlers for finding the exception
stack.
Move to setting up PIR with hard_smp_processor_id fixes the issue.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/platforms/85xx/smp.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c
index d6e4746..190d111 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -48,10 +48,11 @@ smp_85xx_kick_cpu(int nr)
const u64 *cpu_rel_addr;
__iomem u32 *bptr_vaddr;
struct device_node *np;
- int n = 0;
+ int n = 0, hw_cpu = get_hard_smp_processor_id(nr);
int ioremappable;
- WARN_ON (nr < 0 || nr >= NR_CPUS);
+ WARN_ON(nr < 0 || nr >= NR_CPUS);
+ WARN_ON(hw_cpu < 0 || hw_cpu >= NR_CPUS);
pr_debug("smp_85xx_kick_cpu: kick CPU #%d\n", nr);
@@ -79,7 +80,7 @@ smp_85xx_kick_cpu(int nr)
local_irq_save(flags);
- out_be32(bptr_vaddr + BOOT_ENTRY_PIR, nr);
+ out_be32(bptr_vaddr + BOOT_ENTRY_PIR, hw_cpu);
#ifdef CONFIG_PPC32
out_be32(bptr_vaddr + BOOT_ENTRY_ADDR_LOWER, __pa(__early_start));
@@ -88,7 +89,7 @@ smp_85xx_kick_cpu(int nr)
(ulong)(bptr_vaddr + SIZE_BOOT_ENTRY));
/* Wait a bit for the CPU to ack. */
- while ((__secondary_hold_acknowledge != nr) && (++n < 1000))
+ while ((__secondary_hold_acknowledge != hw_cpu) && (++n < 1000))
mdelay(1);
#else
smp_generic_kick_cpu(nr);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH][v2] uio: Support 36-bit physical addresses on 32-bit systems
From: Tabi Timur-B04825 @ 2011-10-13 14:37 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc-dev@ozlabs.org, hjk@hansjkoch.de, gregkh@suse.de,
linux-kernel@vger.kernel.org, Jiang Kai-B18973
In-Reply-To: <1318453063-17349-1-git-send-email-galak@kernel.crashing.org>
On Wed, Oct 12, 2011 at 3:57 PM, Kumar Gala <galak@kernel.crashing.org> wro=
te:
> From: Kai Jiang <Kai.Jiang@freescale.com>
>
> To support >32-bit physical addresses for UIO_MEM_PHYS type we need to
> extend the width of 'addr' in struct uio_mem. =A0Numerous platforms like
> embedded PPC, ARM, and X86 have support for systems with larger physical
> address than logical.
>
> Since 'addr' may contain a physical, logical, or virtual address the
> easiest solution is to just change the type to 'unsigned long long'
> regardless of which type is utilized.
You forgot to update this description.
> =A0struct uio_mem {
> =A0 =A0 =A0 =A0const char =A0 =A0 =A0 =A0 =A0 =A0 =A0*name;
> - =A0 =A0 =A0 unsigned long =A0 =A0 =A0 =A0 =A0 addr;
> + =A0 =A0 =A0 phys_addr_t =A0 =A0 =A0 =A0 =A0 =A0 addr;
Please add a comment here saying:
1) That 'addr' can be a virtual or physical address
2) That the kernel guarantees that sizeof(phys_addr_t) >=3D sizeof(void
*), so it's safe to use phys_addr_t for a virtual pointer.
--=20
Timur Tabi
Linux kernel developer at Freescale=
^ 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