* [PATCH] pseries: double NR_CPUS in defconfig
From: Nishanth Aravamudan @ 2012-09-12 17:47 UTC (permalink / raw)
To: Ben Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
Anticipating growth in coming years, we should ensure we are getting a
good lead on testing.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
diff --git a/arch/powerpc/configs/pseries_defconfig b/arch/powerpc/configs/pseries_defconfig
index 1f65b3c..a0e0e53 100644
--- a/arch/powerpc/configs/pseries_defconfig
+++ b/arch/powerpc/configs/pseries_defconfig
@@ -2,7 +2,7 @@ CONFIG_PPC64=y
CONFIG_ALTIVEC=y
CONFIG_VSX=y
CONFIG_SMP=y
-CONFIG_NR_CPUS=1024
+CONFIG_NR_CPUS=2048
CONFIG_EXPERIMENTAL=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
^ permalink raw reply related
* [PATCH 1/1] drivers/char/tpm: remove tasklet and cleanup
From: Ashley Lai @ 2012-09-12 17:49 UTC (permalink / raw)
To: linux-kernel
Cc: rcj, jmorris, adlai, linux-security-module, tpmdd-devel, adlai,
key, linuxppc-dev
In-Reply-To: <1345670263.25124.7.camel@footlong>
This patch removed the tasklet and moved the wait queue into the
private structure. It also cleaned up the response CRQ path.
Signed-off-by: Ashley Lai <adlai@us.ibm.com>
---
James,
This patch is based on your "next" branch.
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git
Thanks,
Ashley Lai
---
| 81 +++++++++++++++---------------------------
| 5 ++-
2 files changed, 30 insertions(+), 56 deletions(-)
--git a/drivers/char/tpm/tpm_ibmvtpm.c b/drivers/char/tpm/tpm_ibmvtpm.c
index efc4ab3..88a95ea 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.c
+++ b/drivers/char/tpm/tpm_ibmvtpm.c
@@ -38,8 +38,6 @@ static struct vio_device_id tpm_ibmvtpm_device_table[] __devinitdata = {
};
MODULE_DEVICE_TABLE(vio, tpm_ibmvtpm_device_table);
-DECLARE_WAIT_QUEUE_HEAD(wq);
-
/**
* ibmvtpm_send_crq - Send a CRQ request
* @vdev: vio device struct
@@ -83,6 +81,7 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
{
struct ibmvtpm_dev *ibmvtpm;
u16 len;
+ int sig;
ibmvtpm = (struct ibmvtpm_dev *)chip->vendor.data;
@@ -91,22 +90,23 @@ static int tpm_ibmvtpm_recv(struct tpm_chip *chip, u8 *buf, size_t count)
return 0;
}
- wait_event_interruptible(wq, ibmvtpm->crq_res.len != 0);
+ sig = wait_event_interruptible(ibmvtpm->wq, ibmvtpm->res_len != 0);
+ if (sig)
+ return -EINTR;
+
+ len = ibmvtpm->res_len;
- if (count < ibmvtpm->crq_res.len) {
+ if (count < len) {
dev_err(ibmvtpm->dev,
"Invalid size in recv: count=%ld, crq_size=%d\n",
- count, ibmvtpm->crq_res.len);
+ count, len);
return -EIO;
}
spin_lock(&ibmvtpm->rtce_lock);
- memcpy((void *)buf, (void *)ibmvtpm->rtce_buf, ibmvtpm->crq_res.len);
- memset(ibmvtpm->rtce_buf, 0, ibmvtpm->crq_res.len);
- ibmvtpm->crq_res.valid = 0;
- ibmvtpm->crq_res.msg = 0;
- len = ibmvtpm->crq_res.len;
- ibmvtpm->crq_res.len = 0;
+ memcpy((void *)buf, (void *)ibmvtpm->rtce_buf, len);
+ memset(ibmvtpm->rtce_buf, 0, len);
+ ibmvtpm->res_len = 0;
spin_unlock(&ibmvtpm->rtce_lock);
return len;
}
@@ -273,7 +273,6 @@ static int __devexit tpm_ibmvtpm_remove(struct vio_dev *vdev)
int rc = 0;
free_irq(vdev->irq, ibmvtpm);
- tasklet_kill(&ibmvtpm->tasklet);
do {
if (rc)
@@ -372,7 +371,6 @@ static int ibmvtpm_reset_crq(struct ibmvtpm_dev *ibmvtpm)
static int tpm_ibmvtpm_resume(struct device *dev)
{
struct ibmvtpm_dev *ibmvtpm = ibmvtpm_get_data(dev);
- unsigned long flags;
int rc = 0;
do {
@@ -387,10 +385,11 @@ static int tpm_ibmvtpm_resume(struct device *dev)
return rc;
}
- spin_lock_irqsave(&ibmvtpm->lock, flags);
- vio_disable_interrupts(ibmvtpm->vdev);
- tasklet_schedule(&ibmvtpm->tasklet);
- spin_unlock_irqrestore(&ibmvtpm->lock, flags);
+ rc = vio_enable_interrupts(ibmvtpm->vdev);
+ if (rc) {
+ dev_err(dev, "Error vio_enable_interrupts rc=%d\n", rc);
+ return rc;
+ }
rc = ibmvtpm_crq_send_init(ibmvtpm);
if (rc)
@@ -467,7 +466,7 @@ static struct ibmvtpm_crq *ibmvtpm_crq_get_next(struct ibmvtpm_dev *ibmvtpm)
if (crq->valid & VTPM_MSG_RES) {
if (++crq_q->index == crq_q->num_entry)
crq_q->index = 0;
- rmb();
+ smp_rmb();
} else
crq = NULL;
return crq;
@@ -535,11 +534,9 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
ibmvtpm->vtpm_version = crq->data;
return;
case VTPM_TPM_COMMAND_RES:
- ibmvtpm->crq_res.valid = crq->valid;
- ibmvtpm->crq_res.msg = crq->msg;
- ibmvtpm->crq_res.len = crq->len;
- ibmvtpm->crq_res.data = crq->data;
- wake_up_interruptible(&wq);
+ /* len of the data in rtce buffer */
+ ibmvtpm->res_len = crq->len;
+ wake_up_interruptible(&ibmvtpm->wq);
return;
default:
return;
@@ -559,38 +556,19 @@ static void ibmvtpm_crq_process(struct ibmvtpm_crq *crq,
static irqreturn_t ibmvtpm_interrupt(int irq, void *vtpm_instance)
{
struct ibmvtpm_dev *ibmvtpm = (struct ibmvtpm_dev *) vtpm_instance;
- unsigned long flags;
-
- spin_lock_irqsave(&ibmvtpm->lock, flags);
- vio_disable_interrupts(ibmvtpm->vdev);
- tasklet_schedule(&ibmvtpm->tasklet);
- spin_unlock_irqrestore(&ibmvtpm->lock, flags);
-
- return IRQ_HANDLED;
-}
-
-/**
- * ibmvtpm_tasklet - Interrupt handler tasklet
- * @data: ibm vtpm device struct
- *
- * Returns:
- * Nothing
- **/
-static void ibmvtpm_tasklet(void *data)
-{
- struct ibmvtpm_dev *ibmvtpm = data;
struct ibmvtpm_crq *crq;
- unsigned long flags;
- spin_lock_irqsave(&ibmvtpm->lock, flags);
+ /* while loop is needed for initial setup (get version and
+ * get rtce_size). There should be only one tpm request at any
+ * given time.
+ */
while ((crq = ibmvtpm_crq_get_next(ibmvtpm)) != NULL) {
ibmvtpm_crq_process(crq, ibmvtpm);
crq->valid = 0;
- wmb();
+ smp_wmb();
}
- vio_enable_interrupts(ibmvtpm->vdev);
- spin_unlock_irqrestore(&ibmvtpm->lock, flags);
+ return IRQ_HANDLED;
}
/**
@@ -650,9 +628,6 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
goto reg_crq_cleanup;
}
- tasklet_init(&ibmvtpm->tasklet, (void *)ibmvtpm_tasklet,
- (unsigned long)ibmvtpm);
-
rc = request_irq(vio_dev->irq, ibmvtpm_interrupt, 0,
tpm_ibmvtpm_driver_name, ibmvtpm);
if (rc) {
@@ -666,13 +641,14 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
goto init_irq_cleanup;
}
+ init_waitqueue_head(&ibmvtpm->wq);
+
crq_q->index = 0;
ibmvtpm->dev = dev;
ibmvtpm->vdev = vio_dev;
chip->vendor.data = (void *)ibmvtpm;
- spin_lock_init(&ibmvtpm->lock);
spin_lock_init(&ibmvtpm->rtce_lock);
rc = ibmvtpm_crq_send_init(ibmvtpm);
@@ -689,7 +665,6 @@ static int __devinit tpm_ibmvtpm_probe(struct vio_dev *vio_dev,
return rc;
init_irq_cleanup:
- tasklet_kill(&ibmvtpm->tasklet);
do {
rc1 = plpar_hcall_norets(H_FREE_CRQ, vio_dev->unit_address);
} while (rc1 == H_BUSY || H_IS_LONG_BUSY(rc1));
--git a/drivers/char/tpm/tpm_ibmvtpm.h b/drivers/char/tpm/tpm_ibmvtpm.h
index 4296eb4..bd82a79 100644
--- a/drivers/char/tpm/tpm_ibmvtpm.h
+++ b/drivers/char/tpm/tpm_ibmvtpm.h
@@ -38,13 +38,12 @@ struct ibmvtpm_dev {
struct vio_dev *vdev;
struct ibmvtpm_crq_queue crq_queue;
dma_addr_t crq_dma_handle;
- spinlock_t lock;
- struct tasklet_struct tasklet;
u32 rtce_size;
void __iomem *rtce_buf;
dma_addr_t rtce_dma_handle;
spinlock_t rtce_lock;
- struct ibmvtpm_crq crq_res;
+ wait_queue_head_t wq;
+ u16 res_len;
u32 vtpm_version;
};
--
1.7.11.2
^ permalink raw reply related
* Re: [PATCH] of: specify initrd location using 64-bit
From: Cyril Chemparathy @ 2012-09-12 18:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-mips, x86, a-jacquiot, mahesh, linus.walleij,
paul.gortmaker, paulus, hpa, m.szyprowski, jonas, linux,
linux-c6x-dev, nico, david.daney, mingo, suzuki, linux-arm-kernel,
linux, arnd, microblaze-uclinux, devicetree-discuss, msalter,
rob.herring, tglx, bigeasy, blogic, dhowells, monstr,
linux-kernel, ralf, tj, linuxppc-dev
In-Reply-To: <CAMuHMdUuQzD0bq8PifBea2-0Pk7RhmPA0-GAFprsk+vMxMGjGw@mail.gmail.com>
On 9/12/2012 12:16 PM, Geert Uytterhoeven wrote:
> On Wed, Sep 12, 2012 at 6:05 PM, Cyril Chemparathy <cyril@ti.com> wrote:
>> On some PAE architectures, the entire range of physical memory could reside
>> outside the 32-bit limit. These systems need the ability to specify the
>> initrd location using 64-bit numbers.
>>
>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>> use 64-bit numbers instead of the current unsigned long.
>
>> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
>> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>
> Why not phys_addr_t?
>
The rest of the memory specific bits of the device-tree code use u64 for
addresses, and I kept it the same for consistency.
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
--
Thanks
- Cyril
^ permalink raw reply
* Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro
From: Alexander Graf @ 2012-09-12 18:56 UTC (permalink / raw)
To: Mihai Caraman
Cc: Mihai Caraman, <linuxppc-dev@lists.ozlabs.org>,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>
In-Reply-To: <1347455894-30044-1-git-send-email-mihai.caraman@freescale.com>
On 12.09.2012, at 15:18, Mihai Caraman <mihai.caraman@freescale.com> wrote:
> The current form of DO_KVM macro restricts its use to one call per input
> parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
> definition.
> Duplicate calls of DO_KVM are required by distinct implementations of
> exeption handlers which are delegated at runtime.
Not sure I understand what you're trying to achieve here. Please elaborate ;=
)
Alex
> Use a rare label number
> to avoid conflicts with the calling contexts.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/include/asm/kvm_booke_hv_asm.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/kvm_booke_hv_asm.h b/arch/powerpc/in=
clude/asm/kvm_booke_hv_asm.h
> index 30a600f..a37a12a 100644
> --- a/arch/powerpc/include/asm/kvm_booke_hv_asm.h
> +++ b/arch/powerpc/include/asm/kvm_booke_hv_asm.h
> @@ -38,9 +38,9 @@
> #ifdef CONFIG_KVM_BOOKE_HV
> BEGIN_FTR_SECTION
> mtocrf 0x80, r11 /* check MSR[GS] without clobbering reg */
> - bf 3, kvmppc_resume_\intno\()_\srr1
> + bf 3, 1975f
> b kvmppc_handler_\intno\()_\srr1
> -kvmppc_resume_\intno\()_\srr1:
> +1975:
> END_FTR_SECTION_IFSET(CPU_FTR_EMB_HV)
> #endif
> .endm
> --=20
> 1.7.4.1
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] of: specify initrd location using 64-bit
From: Sebastian Andrzej Siewior @ 2012-09-12 19:58 UTC (permalink / raw)
To: Cyril Chemparathy
Cc: linux-mips, x86, a-jacquiot, mahesh, linus.walleij,
paul.gortmaker, paulus, hpa, m.szyprowski, jonas, linux,
linux-c6x-dev, nico, david.daney, mingo, Geert Uytterhoeven,
suzuki, linux, arnd, microblaze-uclinux, devicetree-discuss,
msalter, rob.herring, tglx, linux-arm-kernel, blogic, dhowells,
monstr, linux-kernel, ralf, tj, linuxppc-dev
In-Reply-To: <5050CE33.9060909@ti.com>
On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
>>> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
>>> unsigned long end)
>>> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>>
>> Why not phys_addr_t?
>>
>
> The rest of the memory specific bits of the device-tree code use u64 for
> addresses, and I kept it the same for consistency.
Geert is right here. If it is a physical address, it should be
phys_addr_t.
Sebastian
^ permalink raw reply
* Re: [PATCH] powerpc/p5040: fix dtb build warning of p5040ds.dtb
From: Kumar Gala @ 2012-09-12 20:20 UTC (permalink / raw)
To: Shaohui Xie; +Cc: linuxppc-dev
In-Reply-To: <1347446163-15470-1-git-send-email-Shaohui.Xie@freescale.com>
On Sep 12, 2012, at 5:36 AM, Shaohui Xie wrote:
> Device node adt7461 was wrongly added in p5040ds.dts, it should be =
added
> into i2c instead of localbus, when build p5040ds.dtb, a warning will =
dump:
>=20
> Warning (reg_format): "reg" property in
> /localbus@ffe124000/nand@2,0/adt7461@4c has invalid length (4 bytes)
> (#address-cells =3D=3D 1, #size-cells =3D=3D 1)
>=20
> This was introduced by:
>=20
> commit ea6b1ba692bcb5f6e39f409a78cf8b04fdf23baa
> Author: Jia Hongtao <B38951@freescale.com>
> Date: Tue Aug 28 10:00:55 2012 +0800
>=20
> powerpc: add adt7461 thermal monitor support to applicable boards
>=20
> Add thermal monitor support to following boards:
> P1022DS, MPC8536DS, P2041RDB, P3041DS, P4080DS, P5020DS, P5040DS
>=20
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> based on next branch of =
http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
>=20
> arch/powerpc/boot/dts/p5040ds.dts | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH V10] powerpc/fsl-pci: Unify pci/pcie initialization code
From: Kumar Gala @ 2012-09-12 20:20 UTC (permalink / raw)
To: Jia Hongtao; +Cc: B07421, linuxppc-dev
In-Reply-To: <1346139848-28021-1-git-send-email-B38951@freescale.com>
On Aug 28, 2012, at 2:44 AM, Jia Hongtao wrote:
> We unified the Freescale pci/pcie initialization by changing the =
fsl_pci
> to a platform driver. In previous PCI code architecture the =
initialization
> routine is called at board_setup_arch stage. Now the initialization is =
done
> in probe function which is architectural better. Also It's convenient =
for
> adding PM support for PCI controller in later patch.
>=20
> Now we registered pci controllers as platform devices. So we combine =
two
> initialization code as one platform driver.
>=20
> Signed-off-by: Jia Hongtao <B38951@freescale.com>
> Signed-off-by: Li Yang <leoli@freescale.com>
> Signed-off-by: Chunhe Lan <Chunhe.Lan@freescale.com>
> ---
> Changes for V10:
> * Just update comments for mpc85xx_cds_pci_assign_primary
>=20
> arch/powerpc/platforms/85xx/common.c | 10 +++
> arch/powerpc/platforms/85xx/corenet_ds.c | 34 ++--------
> arch/powerpc/platforms/85xx/ge_imp3a.c | 62 ++++++-----------
> arch/powerpc/platforms/85xx/mpc8536_ds.c | 36 +---------
> arch/powerpc/platforms/85xx/mpc85xx_ads.c | 11 +--
> arch/powerpc/platforms/85xx/mpc85xx_cds.c | 44 +++++++++----
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 14 ++--
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 40 ++---------
> arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 30 +++-----
> arch/powerpc/platforms/85xx/p1010rdb.c | 14 +---
> arch/powerpc/platforms/85xx/p1022_ds.c | 36 +---------
> arch/powerpc/platforms/85xx/p1022_rdk.c | 36 +---------
> arch/powerpc/platforms/85xx/p1023_rds.c | 9 +--
> arch/powerpc/platforms/85xx/p2041_rdb.c | 2 +-
> arch/powerpc/platforms/85xx/p3041_ds.c | 2 +-
> arch/powerpc/platforms/85xx/p4080_ds.c | 2 +-
> arch/powerpc/platforms/85xx/p5020_ds.c | 2 +-
> arch/powerpc/platforms/85xx/p5040_ds.c | 2 +-
> arch/powerpc/platforms/85xx/qemu_e500.c | 4 +-
> arch/powerpc/platforms/85xx/sbc8548.c | 21 +-----
> arch/powerpc/platforms/85xx/socrates.c | 11 +---
> arch/powerpc/platforms/85xx/stx_gp3.c | 13 +---
> arch/powerpc/platforms/85xx/tqm85xx.c | 21 +-----
> arch/powerpc/platforms/85xx/xes_mpc85xx.c | 56 ++-------------
> arch/powerpc/platforms/86xx/gef_ppc9a.c | 12 +--
> arch/powerpc/platforms/86xx/gef_sbc310.c | 13 +---
> arch/powerpc/platforms/86xx/gef_sbc610.c | 12 +--
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 21 ++----
> arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 42 ++----------
> arch/powerpc/platforms/86xx/sbc8641d.c | 14 +---
> arch/powerpc/sysdev/fsl_pci.c | 102 =
+++++++++++++++++-----------
> arch/powerpc/sysdev/fsl_pci.h | 15 +++-
> drivers/edac/mpc85xx_edac.c | 43 +++---------
> 33 files changed, 249 insertions(+), 537 deletions(-)
applied to next
- k=
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/pci: Add IP revision register define for Freescale PCIe controller
From: Kumar Gala @ 2012-09-12 20:20 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev
In-Reply-To: <1346664130-7896-1-git-send-email-tie-fei.zang@freescale.com>
On Sep 3, 2012, at 4:22 AM, Roy Zang wrote:
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
> arch/powerpc/sysdev/fsl_pci.h | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/pci: Use PCIe IP block revision register instead of compatible
From: Kumar Gala @ 2012-09-12 20:20 UTC (permalink / raw)
To: Roy Zang; +Cc: linuxppc-dev
In-Reply-To: <1346664130-7896-2-git-send-email-tie-fei.zang@freescale.com>
On Sep 3, 2012, at 4:22 AM, Roy Zang wrote:
> Freescale PCIe IP block revision bigger than rev2.2 will also need
> redefine the sequence of inbound windows. So change to use IP block
> revision instead of compatible for the judgment.
>
> Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
> ---
>
> arch/powerpc/sysdev/fsl_pci.c | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH] of: specify initrd location using 64-bit
From: Rob Herring @ 2012-09-12 20:23 UTC (permalink / raw)
To: Cyril Chemparathy
Cc: linux-mips, x86, david.daney, linux, paul.gortmaker, paulus, hpa,
m.szyprowski, jonas, linus.walleij, linux, linux-c6x-dev, nico,
a-jacquiot, mingo, suzuki, mahesh, bigeasy, arnd,
microblaze-uclinux, devicetree-discuss, msalter, rob.herring,
tglx, linux-arm-kernel, blogic, dhowells, monstr, linux-kernel,
ralf, tj, linuxppc-dev
In-Reply-To: <1347465937-7056-1-git-send-email-cyril@ti.com>
On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
> On some PAE architectures, the entire range of physical memory could reside
> outside the 32-bit limit. These systems need the ability to specify the
> initrd location using 64-bit numbers.
>
> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> use 64-bit numbers instead of the current unsigned long.
S-o-B?
> ---
> arch/arm/mm/init.c | 2 +-
> arch/c6x/kernel/devicetree.c | 3 +--
> arch/microblaze/kernel/prom.c | 3 +--
> arch/mips/kernel/prom.c | 3 +--
> arch/openrisc/kernel/prom.c | 3 +--
> arch/powerpc/kernel/prom.c | 3 +--
> arch/x86/kernel/devicetree.c | 3 +--
> drivers/of/fdt.c | 10 ++++++----
> include/linux/of_fdt.h | 3 +--
> 9 files changed, 14 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index ad722f1..579792c 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
> __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>
> #ifdef CONFIG_OF_FLATTREE
> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
phys_initrd_start/size need to change too. Not sure about similar things
on other arches.
Does u-boot need similar fixes?
> {
> phys_initrd_start = start;
> phys_initrd_size = end - start;
> diff --git a/arch/c6x/kernel/devicetree.c b/arch/c6x/kernel/devicetree.c
> index bdb56f0..287d0e6 100644
> --- a/arch/c6x/kernel/devicetree.c
> +++ b/arch/c6x/kernel/devicetree.c
> @@ -33,8 +33,7 @@ void __init early_init_devtree(void *params)
>
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/microblaze/kernel/prom.c b/arch/microblaze/kernel/prom.c
> index 4a764cc..cecd42c 100644
> --- a/arch/microblaze/kernel/prom.c
> +++ b/arch/microblaze/kernel/prom.c
> @@ -136,8 +136,7 @@ void __init early_init_devtree(void *params)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
> index 028f6f8..e37e0dc 100644
> --- a/arch/mips/kernel/prom.c
> +++ b/arch/mips/kernel/prom.c
> @@ -41,8 +41,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/openrisc/kernel/prom.c b/arch/openrisc/kernel/prom.c
> index 5869e3f..150215a 100644
> --- a/arch/openrisc/kernel/prom.c
> +++ b/arch/openrisc/kernel/prom.c
> @@ -96,8 +96,7 @@ void __init early_init_devtree(void *params)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 37725e8..ac15f63 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -549,8 +549,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/arch/x86/kernel/devicetree.c b/arch/x86/kernel/devicetree.c
> index b158152..2fbad6b 100644
> --- a/arch/x86/kernel/devicetree.c
> +++ b/arch/x86/kernel/devicetree.c
> @@ -52,8 +52,7 @@ void * __init early_init_dt_alloc_memory_arch(u64 size, u64 align)
> }
>
> #ifdef CONFIG_BLK_DEV_INITRD
> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end)
> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
> {
> initrd_start = (unsigned long)__va(start);
> initrd_end = (unsigned long)__va(end);
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 91a375f..2ff8b7a 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -554,7 +554,8 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)
> */
> void __init early_init_dt_check_for_initrd(unsigned long node)
> {
> - unsigned long start, end, len;
> + u64 start, end;
> + unsigned long len;
> __be32 *prop;
>
> pr_debug("Looking for initrd properties... ");
> @@ -562,15 +563,16 @@ void __init early_init_dt_check_for_initrd(unsigned long node)
> prop = of_get_flat_dt_prop(node, "linux,initrd-start", &len);
> if (!prop)
> return;
> - start = of_read_ulong(prop, len/4);
> + start = of_read_number(prop, len/4);
>
> prop = of_get_flat_dt_prop(node, "linux,initrd-end", &len);
> if (!prop)
> return;
> - end = of_read_ulong(prop, len/4);
> + end = of_read_number(prop, len/4);
>
> early_init_dt_setup_initrd_arch(start, end);
> - pr_debug("initrd_start=0x%lx initrd_end=0x%lx\n", start, end);
> + pr_debug("initrd_start=0x%llx initrd_end=0x%llx\n",
> + (unsigned long long)start, (unsigned long long)end);
> }
> #else
> inline void early_init_dt_check_for_initrd(unsigned long node)
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index ed136ad..4a17939 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -106,8 +106,7 @@ extern u64 dt_mem_next_cell(int s, __be32 **cellp);
> * physical addresses.
> */
> #ifdef CONFIG_BLK_DEV_INITRD
> -extern void early_init_dt_setup_initrd_arch(unsigned long start,
> - unsigned long end);
> +extern void early_init_dt_setup_initrd_arch(u64 start, u64 end);
> #endif
>
> /* Early flat tree scan hooks */
>
^ permalink raw reply
* Re: [PATCH] of: specify initrd location using 64-bit
From: Nicolas Pitre @ 2012-09-12 20:31 UTC (permalink / raw)
To: Rob Herring
Cc: linux-mips, x86, david.daney, bigeasy, paul.gortmaker, paulus,
hpa, m.szyprowski, jonas, linus.walleij, linux, linux-c6x-dev,
a-jacquiot, mahesh, mingo, suzuki, Cyril Chemparathy, linux, arnd,
microblaze-uclinux, devicetree-discuss, msalter, rob.herring,
tglx, linux-arm-kernel, blogic, dhowells, monstr, linux-kernel,
ralf, tj, linuxppc-dev
In-Reply-To: <5050EF3F.6030003@gmail.com>
On Wed, 12 Sep 2012, Rob Herring wrote:
> On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
> > On some PAE architectures, the entire range of physical memory could reside
> > outside the 32-bit limit. These systems need the ability to specify the
> > initrd location using 64-bit numbers.
> >
> > This patch globally modifies the early_init_dt_setup_initrd_arch() function to
> > use 64-bit numbers instead of the current unsigned long.
>
> S-o-B?
>
> > ---
> > arch/arm/mm/init.c | 2 +-
> > arch/c6x/kernel/devicetree.c | 3 +--
> > arch/microblaze/kernel/prom.c | 3 +--
> > arch/mips/kernel/prom.c | 3 +--
> > arch/openrisc/kernel/prom.c | 3 +--
> > arch/powerpc/kernel/prom.c | 3 +--
> > arch/x86/kernel/devicetree.c | 3 +--
> > drivers/of/fdt.c | 10 ++++++----
> > include/linux/of_fdt.h | 3 +--
> > 9 files changed, 14 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > index ad722f1..579792c 100644
> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
> > __tagtable(ATAG_INITRD2, parse_tag_initrd2);
> >
> > #ifdef CONFIG_OF_FLATTREE
> > -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
> > +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>
> phys_initrd_start/size need to change too. Not sure about similar things
> on other arches.
size ?
Nicolas
^ permalink raw reply
* Re: [PATCH] of: specify initrd location using 64-bit
From: Rob Herring @ 2012-09-12 20:56 UTC (permalink / raw)
To: Nicolas Pitre
Cc: linux-mips, x86, david.daney, bigeasy, paul.gortmaker, paulus,
hpa, m.szyprowski, jonas, linus.walleij, linux, linux-c6x-dev,
a-jacquiot, mahesh, mingo, suzuki, Cyril Chemparathy, linux, arnd,
microblaze-uclinux, devicetree-discuss, msalter, rob.herring,
tglx, linux-arm-kernel, blogic, dhowells, monstr, linux-kernel,
ralf, tj, linuxppc-dev
In-Reply-To: <alpine.LFD.2.02.1209121629260.28681@xanadu.home>
On 09/12/2012 03:31 PM, Nicolas Pitre wrote:
> On Wed, 12 Sep 2012, Rob Herring wrote:
>
>> On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
>>> On some PAE architectures, the entire range of physical memory could reside
>>> outside the 32-bit limit. These systems need the ability to specify the
>>> initrd location using 64-bit numbers.
>>>
>>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>>> use 64-bit numbers instead of the current unsigned long.
>>
>> S-o-B?
>>
>>> ---
>>> arch/arm/mm/init.c | 2 +-
>>> arch/c6x/kernel/devicetree.c | 3 +--
>>> arch/microblaze/kernel/prom.c | 3 +--
>>> arch/mips/kernel/prom.c | 3 +--
>>> arch/openrisc/kernel/prom.c | 3 +--
>>> arch/powerpc/kernel/prom.c | 3 +--
>>> arch/x86/kernel/devicetree.c | 3 +--
>>> drivers/of/fdt.c | 10 ++++++----
>>> include/linux/of_fdt.h | 3 +--
>>> 9 files changed, 14 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>>> index ad722f1..579792c 100644
>>> --- a/arch/arm/mm/init.c
>>> +++ b/arch/arm/mm/init.c
>>> @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
>>> __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>>>
>>> #ifdef CONFIG_OF_FLATTREE
>>> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
>>> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>>
>> phys_initrd_start/size need to change too. Not sure about similar things
>> on other arches.
>
> size ?
phys_initrd_size. Arguably, we'll never have a >4GB initrd with a PAE
system or perhaps run into other issues first (like space to decompress
it), but technically the DTS could specify one.
Rob
^ permalink raw reply
* Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro
From: Scott Wood @ 2012-09-12 21:38 UTC (permalink / raw)
To: Alexander Graf
Cc: Mihai Caraman, <linuxppc-dev@lists.ozlabs.org>,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>
In-Reply-To: <F4E2A678-6697-4207-8CEE-2CFB3629F554@suse.de>
On 09/12/2012 01:56 PM, Alexander Graf wrote:
>
>
> On 12.09.2012, at 15:18, Mihai Caraman <mihai.caraman@freescale.com> wrote:
>
>> The current form of DO_KVM macro restricts its use to one call per input
>> parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
>> definition.
>> Duplicate calls of DO_KVM are required by distinct implementations of
>> exeption handlers which are delegated at runtime.
>
> Not sure I understand what you're trying to achieve here. Please elaborate ;)
On 64-bit book3e we compile multiple versions of the TLB miss handlers,
and choose from them at runtime. Without this patch, we get duplicate
label errors if more than one variant of the same exception uses DO_KVM.
-Scott
^ permalink raw reply
* Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro
From: Alexander Graf @ 2012-09-12 21:45 UTC (permalink / raw)
To: Scott Wood
Cc: Mihai Caraman, <linuxppc-dev@lists.ozlabs.org>,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>
In-Reply-To: <505100BD.6020304@freescale.com>
On 12.09.2012, at 23:38, Scott Wood <scottwood@freescale.com> wrote:
> On 09/12/2012 01:56 PM, Alexander Graf wrote:
>>=20
>>=20
>> On 12.09.2012, at 15:18, Mihai Caraman <mihai.caraman@freescale.com> wrot=
e:
>>=20
>>> The current form of DO_KVM macro restricts its use to one call per input=
>>> parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
>>> definition.
>>> Duplicate calls of DO_KVM are required by distinct implementations of
>>> exeption handlers which are delegated at runtime.
>>=20
>> Not sure I understand what you're trying to achieve here. Please elaborat=
e ;)
>=20
> On 64-bit book3e we compile multiple versions of the TLB miss handlers,
> and choose from them at runtime. =20
Why?
> Without this patch, we get duplicate
> label errors if more than one variant of the same exception uses DO_KVM.
Makes sense. The proposed solution also looks good. Just quickly walk me thr=
ough the reasoning for the runtime check again please.
Alex
>=20
> -Scott
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] KVM: PPC: bookehv: Allow duplicate calls of DO_KVM macro
From: Scott Wood @ 2012-09-12 21:54 UTC (permalink / raw)
To: Alexander Graf
Cc: Mihai Caraman, <linuxppc-dev@lists.ozlabs.org>,
<kvm@vger.kernel.org>, <kvm-ppc@vger.kernel.org>
In-Reply-To: <B9A48F7E-664A-4E8A-883F-CEB01068CC2A@suse.de>
On 09/12/2012 04:45 PM, Alexander Graf wrote:
>
>
> On 12.09.2012, at 23:38, Scott Wood <scottwood@freescale.com> wrote:
>
>> On 09/12/2012 01:56 PM, Alexander Graf wrote:
>>>
>>>
>>> On 12.09.2012, at 15:18, Mihai Caraman <mihai.caraman@freescale.com> wrote:
>>>
>>>> The current form of DO_KVM macro restricts its use to one call per input
>>>> parameter set. This is caused by kvmppc_resume_\intno\()_\srr1 symbol
>>>> definition.
>>>> Duplicate calls of DO_KVM are required by distinct implementations of
>>>> exeption handlers which are delegated at runtime.
>>>
>>> Not sure I understand what you're trying to achieve here. Please elaborate ;)
>>
>> On 64-bit book3e we compile multiple versions of the TLB miss handlers,
>> and choose from them at runtime.
>
> Why?
Because one size does not fit all, and we try to not force a separate
kernel build based on what sort of TLB miss handler a piece of hardware
wants. Some of the differences are too large to be sanely handled by
feature fixups.
>> Without this patch, we get duplicate
>> label errors if more than one variant of the same exception uses DO_KVM.
>
> Makes sense. The proposed solution also looks good. Just quickly walk me through the reasoning for the runtime check again please.
To start with, you have a TLB miss handler for when partial hardware
tablewalk is used (only the final page table level is looked up in
hardware, so we still need a TLB miss handler to load indirect entries),
and one where that feature is not available. Then you have the "bolted"
variant used by e5500, which is faster than the generic version because
it doesn't have to deal with recursive faults. So far the bolted
version is the only one with DO_KVM.
I posted a patch to add another variant, for e6500-style hardware
tablewalk, which shares the bolted prolog/epilog (besides prolog/epilog
performance, e6500 is incompatible with the IBM tablewalk code for
various reasons). That caused us to have two DO_KVMs for the same
exception type.
-Scott
^ permalink raw reply
* Re: [PATCH] of: specify initrd location using 64-bit
From: Rob Herring @ 2012-09-12 22:08 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-mips, a-jacquiot, mahesh, linux, paul.gortmaker, paulus,
hpa, m.szyprowski, jonas, linux, linux-c6x-dev, nico, x86, mingo,
suzuki, Cyril Chemparathy, Geert Uytterhoeven, linus.walleij,
arnd, microblaze-uclinux, devicetree-discuss, msalter,
rob.herring, tglx, linux-arm-kernel, blogic, dhowells, monstr,
david.daney, linux-kernel, ralf, tj, linuxppc-dev
In-Reply-To: <5050E965.5080405@linutronix.de>
On 09/12/2012 02:58 PM, Sebastian Andrzej Siewior wrote:
> On 09/12/2012 08:02 PM, Cyril Chemparathy wrote:
>>>> -void __init early_init_dt_setup_initrd_arch(unsigned long start,
>>>> unsigned long end)
>>>> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>>>
>>> Why not phys_addr_t?
>>>
>>
>> The rest of the memory specific bits of the device-tree code use u64 for
>> addresses, and I kept it the same for consistency.
>
> Geert is right here. If it is a physical address, it should be
> phys_addr_t.
While generally true, for the DT specific code I think it should be a
fixed u64. The size of the address is defined by the FDT, not the
kernel. It is very likely we could have a FDT that specifies addresses
in 64-bit values, but then we boot a kernel is compiled for !LPAE.
phys_addr_t is currently sized based on LPAE setting.
Also, this is how the memory and reserved nodes are handled currently,
so we should be consistent.
Rob
^ permalink raw reply
* Re: [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver
From: Nik Mak @ 2012-09-12 22:47 UTC (permalink / raw)
To: Dan Horák; +Cc: Nico Macrionitis, linuxppc-dev
In-Reply-To: <1347466004-14592-1-git-send-email-dan@danny.cz>
Right, as far as i'm concerced that patch always worked without issues.
--nico
On Wed, 12 Sep 2012 18:06:44 +0200
Dan Hor=E1k <dan@danny.cz> wrote:
> I'm reviving an old patch from 2009 that adds support for GXT4000P and GX=
T6500P
> adapter to the gxt4500 driver.
>=20
> See threads at http://marc.info/?l=3Dlinux-fbdev-devel&m=3D12434508021695=
2&w=3D2
> and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
> for more details.
>=20
> This patch adds support for GXT4000P and GXT6500P cards found on some
> IBM pSeries machines.
> GXT4000P/6000P and GXT4500P/6500P couples are identical from
> software's point of view and are based on the same Raster Engine
> (RC1000), except for a different reference clock for the PLL.
> GXT6x00P models are equipped with an additional Geometry Engine
> (GT1000) but this driver doesn't use it.
>=20
> Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
> Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
> Tested-by: Dan Hor=E1k <dan@danny.cz>
> ---
> drivers/video/Kconfig | 8 +++++---
> drivers/video/gxt4500.c | 15 +++++++++++++--
> 2 files changed, 18 insertions(+), 5 deletions(-)
>=20
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 0217f74..c89eb1e 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2167,14 +2167,16 @@ config FB_PNX4008_DUM_RGB
> Say Y here to enable support for PNX4008 RGB Framebuffer
> =20
> config FB_IBM_GXT4500
> - tristate "Framebuffer support for IBM GXT4500P adaptor"
> + tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adapto=
rs"
> depends on FB && PPC
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> ---help---
> - Say Y here to enable support for the IBM GXT4500P display
> - adaptor, found on some IBM System P (pSeries) machines.
> + Say Y here to enable support for the IBM GXT4000P/6000P and
> + GXT4500P/6500P display adaptor based on Raster Engine RC1000,
> + found on some IBM System P (pSeries) machines. This driver
> + doesn't use Geometry Engine GT1000.
> =20
> config FB_PS3
> tristate "PS3 GPU framebuffer driver"
> diff --git a/drivers/video/gxt4500.c b/drivers/video/gxt4500.c
> index 0fad23f..755c3e7 100644
> --- a/drivers/video/gxt4500.c
> +++ b/drivers/video/gxt4500.c
> @@ -1,5 +1,6 @@
> /*
> - * Frame buffer device for IBM GXT4500P and GXT6000P display adaptors
> + * Frame buffer device for IBM GXT4500P/6500P and GXT4000P/6000P
> + * display adaptors
> *
> * Copyright (C) 2006 Paul Mackerras, IBM Corp. <paulus@samba.org>
> */
> @@ -14,6 +15,8 @@
> #include <linux/string.h>
> =20
> #define PCI_DEVICE_ID_IBM_GXT4500P 0x21c
> +#define PCI_DEVICE_ID_IBM_GXT6500P 0x21b
> +#define PCI_DEVICE_ID_IBM_GXT4000P 0x16e
> #define PCI_DEVICE_ID_IBM_GXT6000P 0x170
> =20
> /* GXT4500P registers */
> @@ -173,6 +176,8 @@ static const struct fb_videomode defaultmode __devini=
tdata =3D {
> /* List of supported cards */
> enum gxt_cards {
> GXT4500P,
> + GXT6500P,
> + GXT4000P,
> GXT6000P
> };
> =20
> @@ -182,6 +187,8 @@ static const struct cardinfo {
> const char *cardname;
> } cardinfo[] =3D {
> [GXT4500P] =3D { .refclk_ps =3D 9259, .cardname =3D "IBM GXT4500P" },
> + [GXT6500P] =3D { .refclk_ps =3D 9259, .cardname =3D "IBM GXT6500P" },
> + [GXT4000P] =3D { .refclk_ps =3D 40000, .cardname =3D "IBM GXT4000P" },
> [GXT6000P] =3D { .refclk_ps =3D 40000, .cardname =3D "IBM GXT6000P" },
> };
> =20
> @@ -736,6 +743,10 @@ static void __devexit gxt4500_remove(struct pci_dev =
*pdev)
> static const struct pci_device_id gxt4500_pci_tbl[] =3D {
> { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4500P),
> .driver_data =3D GXT4500P },
> + { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6500P),
> + .driver_data =3D GXT6500P },
> + { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4000P),
> + .driver_data =3D GXT4000P },
> { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6000P),
> .driver_data =3D GXT6000P },
> { 0 }
> @@ -768,7 +779,7 @@ static void __exit gxt4500_exit(void)
> module_exit(gxt4500_exit);
> =20
> MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
> -MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6000P");
> +MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6500P and GXT4000P/600=
0P");
> MODULE_LICENSE("GPL");
> module_param(mode_option, charp, 0);
> MODULE_PARM_DESC(mode_option, "Specify resolution as \"<xres>x<yres>[-<b=
pp>][@<refresh>]\"");
> --=20
> 1.7.7.6
>=20
--=20
Sent from Genesi EfikaMX Smartbook - Freescale i.MX51 based
^ permalink raw reply
* [PATCH] powerpc: fix typo in PTRS_PER_PUD
From: Scott Wood @ 2012-09-12 23:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Aneesh Kumar K.V
PTRS_PER_PUD should be based on PUD_INDEX_SIZE, not PMD_INDEX_SIZE. We
got away with it because PUD and PMD had the same index size, but this is
no longer true with Aneesh's patchset to support a 46-bit user effective
address space.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/include/asm/pgtable-ppc64-4k.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64-4k.h b/arch/powerpc/include/asm/pgtable-ppc64-4k.h
index b3eccf2..12798c9 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64-4k.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64-4k.h
@@ -19,7 +19,7 @@
#define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
#define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
-#define PTRS_PER_PUD (1 << PMD_INDEX_SIZE)
+#define PTRS_PER_PUD (1 << PUD_INDEX_SIZE)
#define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
/* PMD_SHIFT determines what a second-level page table entry can map */
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] powerpc: fix typo in PTRS_PER_PUD
From: Benjamin Herrenschmidt @ 2012-09-12 23:06 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Aneesh Kumar K.V
In-Reply-To: <20120912230009.GA17226@buserror.net>
On Wed, 2012-09-12 at 18:00 -0500, Scott Wood wrote:
> PTRS_PER_PUD should be based on PUD_INDEX_SIZE, not PMD_INDEX_SIZE. We
> got away with it because PUD and PMD had the same index size, but this is
> no longer true with Aneesh's patchset to support a 46-bit user effective
> address space.
Ah, my typo :-) Cool, I'll make sure to apply that before Aneesh
patches.
Thanks,
Ben.
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/include/asm/pgtable-ppc64-4k.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc64-4k.h b/arch/powerpc/include/asm/pgtable-ppc64-4k.h
> index b3eccf2..12798c9 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc64-4k.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc64-4k.h
> @@ -19,7 +19,7 @@
>
> #define PTRS_PER_PTE (1 << PTE_INDEX_SIZE)
> #define PTRS_PER_PMD (1 << PMD_INDEX_SIZE)
> -#define PTRS_PER_PUD (1 << PMD_INDEX_SIZE)
> +#define PTRS_PER_PUD (1 << PUD_INDEX_SIZE)
> #define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
>
> /* PMD_SHIFT determines what a second-level page table entry can map */
^ permalink raw reply
* Re: [PATCH] of: specify initrd location using 64-bit
From: Cyril Chemparathy @ 2012-09-12 23:45 UTC (permalink / raw)
To: Rob Herring
Cc: linux-mips, x86, david.daney, linux, paul.gortmaker, paulus, hpa,
m.szyprowski, jonas, linus.walleij, linux, linux-c6x-dev, nico,
a-jacquiot, mingo, suzuki, mahesh, bigeasy, arnd,
microblaze-uclinux, devicetree-discuss, msalter, rob.herring,
tglx, linux-arm-kernel, blogic, dhowells, monstr, linux-kernel,
ralf, tj, linuxppc-dev
In-Reply-To: <5050EF3F.6030003@gmail.com>
On 9/12/2012 4:23 PM, Rob Herring wrote:
> On 09/12/2012 11:05 AM, Cyril Chemparathy wrote:
>> On some PAE architectures, the entire range of physical memory could reside
>> outside the 32-bit limit. These systems need the ability to specify the
>> initrd location using 64-bit numbers.
>>
>> This patch globally modifies the early_init_dt_setup_initrd_arch() function to
>> use 64-bit numbers instead of the current unsigned long.
>
> S-o-B?
>
Sorry about that, will include in v2.
[...]
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -76,7 +76,7 @@ static int __init parse_tag_initrd2(const struct tag *tag)
>> __tagtable(ATAG_INITRD2, parse_tag_initrd2);
>>
>> #ifdef CONFIG_OF_FLATTREE
>> -void __init early_init_dt_setup_initrd_arch(unsigned long start, unsigned long end)
>> +void __init early_init_dt_setup_initrd_arch(u64 start, u64 end)
>
> phys_initrd_start/size need to change too. Not sure about similar things
> on other arches.
>
I've fixed phys_initrd_start (not size) in another patch, please see [1].
> Does u-boot need similar fixes?
>
We aren't there yet :-) We are currently running this platform without
u-boot.
[1] http://permalink.gmane.org/gmane.linux.kernel/1356713
--
Thanks
- Cyril
^ permalink raw reply
* Re: [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver
From: Benjamin Herrenschmidt @ 2012-09-13 0:01 UTC (permalink / raw)
To: Dan Horák; +Cc: linuxppc-dev, Nico Macrionitis, Giuseppe Coviello
In-Reply-To: <1347452412-7129-1-git-send-email-dan@danny.cz>
On Wed, 2012-09-12 at 14:20 +0200, Dan Horák wrote:
> I'm reviving an old patch from 2009 that adds support for GXT4000P and GXT6500P
> adapter to the gxt4500 driver.
Who is the original author ?
Cheers,
Ben.
> See threads at http://marc.info/?l=linux-fbdev-devel&m=124345080216952&w=2
> and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.html
> for more details.
>
> This patch adds support for GXT4000P and GXT6500P cards found on some
> IBM pSeries machines.
> GXT4000P/6000P and GXT4500P/6500P couples are identical from
> software's point of view and are based on the same Raster Engine
> (RC1000), except for a different reference clock for the PLL.
> GXT6x00P models are equipped with an additional Geometry Engine
> (GT1000) but this driver doesn't use it.
>
> Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
> Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
> Tested-by: Dan Horák <dan@danny.cz>
> ---
> drivers/video/Kconfig | 8 +++++---
> drivers/video/gxt4500.c | 15 +++++++++++++--
> 2 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
> index 0217f74..c89eb1e 100644
> --- a/drivers/video/Kconfig
> +++ b/drivers/video/Kconfig
> @@ -2167,14 +2167,16 @@ config FB_PNX4008_DUM_RGB
> Say Y here to enable support for PNX4008 RGB Framebuffer
>
> config FB_IBM_GXT4500
> - tristate "Framebuffer support for IBM GXT4500P adaptor"
> + tristate "Framebuffer support for IBM GXT4000P/4500P/6000P/6500P adaptors"
> depends on FB && PPC
> select FB_CFB_FILLRECT
> select FB_CFB_COPYAREA
> select FB_CFB_IMAGEBLIT
> ---help---
> - Say Y here to enable support for the IBM GXT4500P display
> - adaptor, found on some IBM System P (pSeries) machines.
> + Say Y here to enable support for the IBM GXT4000P/6000P and
> + GXT4500P/6500P display adaptor based on Raster Engine RC1000,
> + found on some IBM System P (pSeries) machines. This driver
> + doesn't use Geometry Engine GT1000.
>
> config FB_PS3
> tristate "PS3 GPU framebuffer driver"
> diff --git a/drivers/video/gxt4500.c b/drivers/video/gxt4500.c
> index 0fad23f..755c3e7 100644
> --- a/drivers/video/gxt4500.c
> +++ b/drivers/video/gxt4500.c
> @@ -1,5 +1,6 @@
> /*
> - * Frame buffer device for IBM GXT4500P and GXT6000P display adaptors
> + * Frame buffer device for IBM GXT4500P/6500P and GXT4000P/6000P
> + * display adaptors
> *
> * Copyright (C) 2006 Paul Mackerras, IBM Corp. <paulus@samba.org>
> */
> @@ -14,6 +15,8 @@
> #include <linux/string.h>
>
> #define PCI_DEVICE_ID_IBM_GXT4500P 0x21c
> +#define PCI_DEVICE_ID_IBM_GXT6500P 0x21b
> +#define PCI_DEVICE_ID_IBM_GXT4000P 0x16e
> #define PCI_DEVICE_ID_IBM_GXT6000P 0x170
>
> /* GXT4500P registers */
> @@ -173,6 +176,8 @@ static const struct fb_videomode defaultmode __devinitdata = {
> /* List of supported cards */
> enum gxt_cards {
> GXT4500P,
> + GXT6500P,
> + GXT4000P,
> GXT6000P
> };
>
> @@ -182,6 +187,8 @@ static const struct cardinfo {
> const char *cardname;
> } cardinfo[] = {
> [GXT4500P] = { .refclk_ps = 9259, .cardname = "IBM GXT4500P" },
> + [GXT6500P] = { .refclk_ps = 9259, .cardname = "IBM GXT6500P" },
> + [GXT4000P] = { .refclk_ps = 40000, .cardname = "IBM GXT4000P" },
> [GXT6000P] = { .refclk_ps = 40000, .cardname = "IBM GXT6000P" },
> };
>
> @@ -736,6 +743,10 @@ static void __devexit gxt4500_remove(struct pci_dev *pdev)
> static const struct pci_device_id gxt4500_pci_tbl[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4500P),
> .driver_data = GXT4500P },
> + { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6500P),
> + .driver_data = GXT6500P },
> + { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT4000P),
> + .driver_data = GXT4000P },
> { PCI_DEVICE(PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_GXT6000P),
> .driver_data = GXT6000P },
> { 0 }
> @@ -768,7 +779,7 @@ static void __exit gxt4500_exit(void)
> module_exit(gxt4500_exit);
>
> MODULE_AUTHOR("Paul Mackerras <paulus@samba.org>");
> -MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6000P");
> +MODULE_DESCRIPTION("FBDev driver for IBM GXT4500P/6500P and GXT4000P/6000P");
> MODULE_LICENSE("GPL");
> module_param(mode_option, charp, 0);
> MODULE_PARM_DESC(mode_option, "Specify resolution as \"<xres>x<yres>[-<bpp>][@<refresh>]\"");
^ permalink raw reply
* RE: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23
From: Huang Changming-R66093 @ 2012-09-13 2:02 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-mmc@vger.kernel.org, Chris Ball,
linuxppc-dev@lists.ozlabs.org list, Anton Vorontsov
In-Reply-To: <8B1F0805-759E-417A-B787-40DF197896F3@kernel.crashing.org>
> >
> >> -----Original Message-----
> >> From: Chris Ball [mailto:cjb@laptop.org]
> >> Sent: Wednesday, September 12, 2012 4:59 AM
> >> To: Kumar Gala
> >> Cc: Huang Changming-R66093; linuxppc-dev@lists.ozlabs.org list;
> >> linux- mmc@vger.kernel.org; Anton Vorontsov
> >> Subject: Re: [PATCH 2/3] powerpc/esdhc: add property to disable the
> >> CMD23
> >>
> >> Hi,
> >>
> >> On Tue, Sep 11 2012, Kumar Gala wrote:
> >>> thanks for the info. Do you know what's required on controller side
> >>> to handle cards that support CMD23?
> >>>
> >>> I'm trying to figure out if older controller's on FSL SoCs are
> >>> missing some feature to allow CMD23 to work (vs Auto-CMD23).
> >>
> >> It seems plausible that it's just not implemented on these controllers=
.
> >> It's a little strange, since the command's been specified for so long
> >> and we haven't seen any other controllers with problems. The patch
> >> would be correct if this is true.
> >>
> >
> > I didn't find any description about it, but after testing on FSL
> silicones, I got this result:
> > Some silicones support this command, and some silicones don't support
> it, which will cause I/O error.
>=20
> Can you list out which SoCs support it and which don't. Having this list
> will be useful in understanding which controller versions supported it.
>=20
P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) supp=
ort it.
^ permalink raw reply
* Re: [PATCH 5/5] ASoC: fsl: mpc5200 remove pcm030 and efika audio fabric
From: Mark Brown @ 2012-09-13 4:27 UTC (permalink / raw)
To: Eric Millbrandt
Cc: alsa-devel@alsa-project.org, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <0A40042D85E7C84DB443060EC44B3FD336D854FEE2@dekaexchange07.deka.local>
On Wed, Sep 12, 2012 at 10:05:33AM -0400, Eric Millbrandt wrote:
Please fix your mailer to word wrap within paragraphs.
> On 2012-09-11 Mark Brown wrote:
> > I only noticed DT bindings being added for pcm030, not for efika?
> When I looked I didn't see the Efika (PPC 5200B) DT in-tree. It only
> appears to exist out-of-tree,
Hrm, well - that's not terribly clever. It'll mean a regression on
existing systems and since they're clearly taking advantage of the
ability to distribute the device tree separately... we'd really want
some sort of backwards compatibility to avoid breaking upgrades. Not
sure what the normal way of doing that is.
^ permalink raw reply
* Re: [PATCH] add GXT4000P and GXT6500P support to the gxt4500 driver
From: Geert Uytterhoeven @ 2012-09-13 5:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Dan Horák, linuxppc-dev, Nico Macrionitis, Giuseppe Coviello
In-Reply-To: <1347494498.2276.19.camel@pasglop>
On Thu, Sep 13, 2012 at 2:01 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2012-09-12 at 14:20 +0200, Dan Hor=C3=A1k wrote:
>> I'm reviving an old patch from 2009 that adds support for GXT4000P and G=
XT6500P
>> adapter to the gxt4500 driver.
>
> Who is the original author ?
Signed-off-by: Nico Macrionitis <acrux@cruxppc.org>
Signed-off-by: Giuseppe Coviello <cjg@cruxppc.org>
It even has your ack (albeit not in canonical form ;-), cfr.
>> See threads at http://marc.info/?l=3Dlinux-fbdev-devel&m=3D1243450802169=
52&w=3D2
>> and https://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072672.htm=
l
>> for more details.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
.org
In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] of: specify initrd location using 64-bit
From: Sebastian Andrzej Siewior @ 2012-09-13 6:47 UTC (permalink / raw)
To: Rob Herring
Cc: linux-mips, a-jacquiot, mahesh, linux, paul.gortmaker, paulus,
hpa, m.szyprowski, jonas, linux, linux-c6x-dev, nico, x86, mingo,
suzuki, Cyril Chemparathy, Geert Uytterhoeven, linus.walleij,
arnd, microblaze-uclinux, devicetree-discuss, msalter,
rob.herring, tglx, linux-arm-kernel, blogic, dhowells, monstr,
david.daney, linux-kernel, ralf, tj, linuxppc-dev
In-Reply-To: <505107DF.5020105@gmail.com>
On 09/13/2012 12:08 AM, Rob Herring wrote:
>> Geert is right here. If it is a physical address, it should be
>> phys_addr_t.
>
> While generally true, for the DT specific code I think it should be a
> fixed u64. The size of the address is defined by the FDT, not the
> kernel. It is very likely we could have a FDT that specifies addresses
> in 64-bit values, but then we boot a kernel is compiled for !LPAE.
> phys_addr_t is currently sized based on LPAE setting.
If your kernel is 32bit without PAE and your DTB address is >32ibt than
you can't handle it. If you don't notice this in your dt code than you
remap the wrong memory ioremap().
>
> Rob
>
Sebastian
^ 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