* Re: of_iomap and request_mem_region
From: Arnd Bergmann @ 2008-02-10 3:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <9e4733910802091859o3e91b6f6y4b0e6b31f722d8e6@mail.gmail.com>
On Sunday 10 February 2008, Jon Smirl wrote:
> On 2/9/08, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Sunday 10 February 2008, Jon Smirl wrote:
> > > of_iomap doesn't implicitly do a request_mem_region(). How should
> > > request_mem_region() be handled? When using of_iomap you don't get the
> > > length of the region back so it isn't easy to call request_mem_region.
> > >
> > > What about adding a third param to of_iomap for the driver name? If it
> > > is non-null also do the request region. If it is null check to make
> > > sure the region has already be requested.
> >
> > I'd prefer changing of_iomap so that it gets the of_device instead of
> > the device_node. That would help us do two changes at once:
> >
> > 1. call request_mem_region using dev->driver->name, as you mentioned.
> > 2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
> > so that we can kill all the calls to iounmap in the cleanup path
> > of OF drivers.
> >
> > maybe we can do a new ofm_iomap interface first, and then move
> > drivers over to use that one.
>
> There are only four drivers using of_iomap.
$ git-ls-files | xargs grep of_iomap | cut -f 1 -d: | uniq | wc -l
19
Unfortunately, many of them don't even use an of_device, so the
conversion is not trivial.
> There are a lot of drivers using of_address_to_resource. They could
> probably be converted to of_iomap if it gets changed. All of the ones
> I checked follow the of_address_to_resource with a request_resource
> call.
Right, but again, we are still in the progress of converting drivers
from using of_find_node_by_type() and similar to of_platform_driver.
If we don't have an of_device, the interface as I would prefer
it doesn't work.
Arnd <><
^ permalink raw reply
* Re: of_iomap and request_mem_region
From: Jon Smirl @ 2008-02-10 2:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200802100345.54580.arnd@arndb.de>
On 2/9/08, Arnd Bergmann <arnd@arndb.de> wrote:
> On Sunday 10 February 2008, Jon Smirl wrote:
> > of_iomap doesn't implicitly do a request_mem_region(). How should
> > request_mem_region() be handled? When using of_iomap you don't get the
> > length of the region back so it isn't easy to call request_mem_region.
> >
> > What about adding a third param to of_iomap for the driver name? If it
> > is non-null also do the request region. If it is null check to make
> > sure the region has already be requested.
>
> I'd prefer changing of_iomap so that it gets the of_device instead of
> the device_node. That would help us do two changes at once:
>
> 1. call request_mem_region using dev->driver->name, as you mentioned.
> 2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
> so that we can kill all the calls to iounmap in the cleanup path
> of OF drivers.
>
> maybe we can do a new ofm_iomap interface first, and then move
> drivers over to use that one.
There are only four drivers using of_iomap. It is not much work to
change them. Looking at them I don't see any that request the
resource. That's probably because they don't have the length needed to
make the call.
There are a lot of drivers using of_address_to_resource. They could
probably be converted to of_iomap if it gets changed. All of the ones
I checked follow the of_address_to_resource with a request_resource
call.
>
> Arnd <><
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: of_iomap and request_mem_region
From: Arnd Bergmann @ 2008-02-10 2:45 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <9e4733910802091838x3e596debj113089faef08c1c8@mail.gmail.com>
On Sunday 10 February 2008, Jon Smirl wrote:
> of_iomap doesn't implicitly do a request_mem_region(). =A0How should
> request_mem_region() be handled? When using of_iomap you don't get the
> length of the region back so it isn't easy to call request_mem_region.
>=20
> What about adding a third param to of_iomap for the driver name? If it
> is non-null also do the request region. If it is null check to make
> sure the region has already be requested.
I'd prefer changing of_iomap so that it gets the of_device instead of
the device_node. That would help us do two changes at once:
1. call request_mem_region using dev->driver->name, as you mentioned.
2. use managed registrations, as lib/devres.c does e.g. in pcim_iomap,
so that we can kill all the calls to iounmap in the cleanup path
of OF drivers.
maybe we can do a new ofm_iomap interface first, and then move
drivers over to use that one.
Arnd <><
^ permalink raw reply
* of_iomap and request_mem_region
From: Jon Smirl @ 2008-02-10 2:38 UTC (permalink / raw)
To: Linux/PPC Development
of_iomap doesn't implicitly do a request_mem_region(). How should
request_mem_region() be handled? When using of_iomap you don't get the
length of the region back so it isn't easy to call request_mem_region.
What about adding a third param to of_iomap for the driver name? If it
is non-null also do the request region. If it is null check to make
sure the region has already be requested.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* HDLC driver - dev_free_skb_irq causes Segfault
From: Russell McGuire @ 2008-02-10 2:32 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]
All,
So I am in the process of debugging my newly established HDLC driver.
More or less modeled after a simplified gianfar / ucc_geth idea.
However, after loading, etc. and using the following commands
-> insmod hdlc-8360.ko
-> sethdlc hdlc0 hdlc-eth
-> ifconfig hdlc0 up 192.168.1.100
All is well, and I am seeing IDL interrupts. Great.
Now I go to ping an address like,
ping 192.168.1.101
I can see that I get the start_xmit function, the IRQ from the QE comes back
and reports the TXBD as successfully sent.
Here is the problem, when I goto free the skb in the tx_handler, I get a
'Unable to Handle Kernel Paging Request for data at address 0x00000000'
Even though for the life of me, I can't see any pointers that are at address
zero.
I have checked the pointer value I am passing in, and indeed it is the exact
same pointer I am receiving from the original
start-xmit call..
Are we supposed to copy the skb? And free it immediately in the start_xmit?
Some special way to store the pointer?
I have tried
txbd->buf = skb->data;
txbd->buf = virt_to_phys(skb->data);
etc.. and various other ways to save that I have seen in the gianfar and
ucc_geth drivers.
My tx_sk_buff** is identical as alloced the same way.
Anyone have any ideas?
-Russ
[-- Attachment #2: Type: text/html, Size: 8796 bytes --]
^ permalink raw reply
* Ebony development board
From: Zoltan HERPAI @ 2008-02-09 19:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I've recently got an Ebony board (440GP) with the original bootloader
(440GP 1.18 ROM Monitor) which I would like to replace with U-boot. Is
there a way to boot an U-boot image via TFTP to replace the bootloader,
or is it possible only with using a JTAG? I've googled through the
mailing list, but most of the related hits are dated back in 2004-2005,
they say no, one have to use JTAG, but some time passed since then, and
I would like to know if there is a way for this.
Thanks in advance,
Zoltan HERPAI
^ permalink raw reply
* Re: [PATCH 07/18] ide: factor out devices init from ide_init_port_data()
From: Sergei Shtylyov @ 2008-02-09 18:10 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004509.17746.70379.sendpatchset@localhost.localdomain>
Bartlomiej Zolnierkiewicz wrote:
> * Factor out devices init from ide_init_port_data() to
> ide_port_init_devices_data().
> While at it:
> * Add explicit clearing of IDE device structure.
> There should be no functionality changes caused by this patch.
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 06/18] ide: factor out code unregistering devices from ide_unregister()
From: Sergei Shtylyov @ 2008-02-09 18:07 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <20080208004502.17746.73284.sendpatchset@localhost.localdomain>
Bartlomiej Zolnierkiewicz wrote:
> Factor out code unregistering devices from ide_unregister() to
> ide_port_unregister_devices().
> Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
MBR, Sergei
^ permalink raw reply
* [PATCH] Fix for Freescale ppc cores: major revision detection
From: Martin Langer @ 2008-02-09 17:47 UTC (permalink / raw)
To: linuxppc-dev
Ppc cores by Freescale are using the configuration field instead of the
major revision field for their major revision number. Those field
definitions come from include/asm-powerpc/reg.h.
Look at the pdf below and you will see that PVR_MAJ() does a wrong shift
for ppc cores by Freescale. This patch fixes it.
http://www.freescale.com/files/archives/doc/support_info/PPCPVR.pdf
Signed-Off-By: Martin Langer <martin-langer@gmx.de>
--- arch/powerpc/kernel/setup-common.c.ORIGINAL 2008-02-08 22:22:56.000000000 +0100
+++ arch/powerpc/kernel/setup-common.c 2008-02-09 18:18:36.000000000 +0100
@@ -241,7 +241,7 @@
/* If we are a Freescale core do a simple check so
* we dont have to keep adding cases in the future */
if (PVR_VER(pvr) & 0x8000) {
- maj = PVR_MAJ(pvr);
+ maj = (pvr >> 8) & 0xF;
min = PVR_MIN(pvr);
} else {
switch (PVR_VER(pvr)) {
^ permalink raw reply
* Re: porting xenomaii for power pc 750Cxe based SBC
From: Wolfgang Grandegger @ 2008-02-09 16:11 UTC (permalink / raw)
To: rakesh bk; +Cc: linuxppc-embedded
In-Reply-To: <43455a600802070411w42b6745aqf87fa3ae88dcaf8c@mail.gmail.com>
rakesh bk wrote:
> Hello Everyone,
>
> Iam Trying to port the xenomai-2.2.0 using the
> "adeos-ipipe-2.6.14-ppc-1.3-05.patch" to linux-kernel 2.6.14( Vanilla)
> to our custom based SBC, After applying patches as i get Enough printk's
> on my console , I get Stucked after UNMASKING of Ethernet Irq The
> following are the printk messages after i tried to boot the image. can i
> know what the actual problem is ...........
This mail is off topic. Please repost on the Xenomai-help mailing list
(https://gna.org/mail/?group=xenomai). As you can see from your boot
log, already the Xenomai initialization fails.
Wolfgang.
^ permalink raw reply
* [patch 5/6] PS3: Sys-manager code cleanup
From: Geoff Levand @ 2008-02-08 22:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080208224723.029462363@am.sony.com>
General code cleanups for PS3 system-manager:
o Move all MODULE_ macros to bottom.
o Correct PS3_SM_WAKE_P_O_R value.
o Enhance comment on wakeup source values.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/ps3/ps3-sys-manager.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -28,10 +28,6 @@
#include "vuart.h"
-MODULE_AUTHOR("Sony Corporation");
-MODULE_LICENSE("GPL v2");
-MODULE_DESCRIPTION("PS3 System Manager");
-
/**
* ps3_sys_manager - PS3 system manager driver.
*
@@ -181,7 +177,9 @@ enum ps3_sys_manager_next_op {
* @PS3_SM_WAKE_P_O_R: Power on reset.
*
* Additional wakeup sources when specifying PS3_SM_NEXT_OP_SYS_SHUTDOWN.
- * System will always wake from the PS3_SM_WAKE_DEFAULT sources.
+ * The system will always wake from the PS3_SM_WAKE_DEFAULT sources.
+ * Sources listed here are the only ones available to guests in the
+ * other-os lpar.
*/
enum ps3_sys_manager_wake_source {
@@ -189,7 +187,7 @@ enum ps3_sys_manager_wake_source {
PS3_SM_WAKE_DEFAULT = 0,
PS3_SM_WAKE_RTC = 0x00000040,
PS3_SM_WAKE_RTC_ERROR = 0x00000080,
- PS3_SM_WAKE_P_O_R = 0x10000000,
+ PS3_SM_WAKE_P_O_R = 0x80000000,
};
/**
@@ -699,4 +697,7 @@ static int __init ps3_sys_manager_init(v
module_init(ps3_sys_manager_init);
/* Module remove not supported. */
+MODULE_AUTHOR("Sony Corporation");
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("PS3 System Manager");
MODULE_ALIAS(PS3_MODULE_ALIAS_SYSTEM_MANAGER);
--
^ permalink raw reply
* Could the DTS experts look at this?
From: Sean MacLennan @ 2008-02-08 23:30 UTC (permalink / raw)
To: LinuxPPC-dev
The Rev B warp is moving to a 4M NOR / 256M NAND flash setup from the
current 64M NOR / 64M NAND. I would like to keep support for the 64M NOR
so I modified the boot code to be a bit more dynamic. Here is the new
NOR parition layout in the DTS:
nor_flash@0,0 {
compatible = "amd,s29gl512n", "cfi-flash";
bank-width = <2>;
reg = <0 0 4000000>;
#address-cells = <1>;
#size-cells = <1>;
partition@300000 {
label = "fpga";
reg = <300000 40000>;
};
partition@340000 {
label = "env";
reg = <340000 40000>;
};
partition@380000 {
label = "u-boot";
reg = <380000 80000>;
};
};
Yes, the top of the NOR will be empty. Here is the code from
cuboot-warp.c to handle fixups for the 64M flash:
static void warp_fixup_one_nor(u32 from, u32 to)
{
void *devp;
char name[40];
u32 v[2];
sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);
devp = finddevice(name);
if (!devp) return;
if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
v[0] = to;
setprop(devp, "reg", v, sizeof(v));
printf("NOR 64M fixup %x -> %x\n", from, to);
}
}
static void warp_fixups(void)
{
unsigned long sysclk = 66000000;
ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
ibm4xx_sdram_fixup_memsize();
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
dt_fixup_mac_addresses(&bd.bi_enetaddr);
/* Fixup for 64M flash on Rev A boards. */
if(bd.bi_flashsize == 0x4000000) {
warp_fixup_one_nor(0x300000, 0x3f00000);
warp_fixup_one_nor(0x340000, 0x3f40000);
warp_fixup_one_nor(0x380000, 0x3f80000);
}
}
I have tested this with the 64M NOR, and it seems to work. However, are
there going to be problems with the partition name not matching the reg
address entry?
If anybody has suggestions on better ways to do this, fire away.
And looking at this code, and other board ports, why is sysclk a local
variable and all the other numbers hardcoded in the args? I left it the
same way as the others but it does look a bit strange.
Cheers,
Sean
^ permalink raw reply
* [patch 6/6] PS3: Update sys-manager button events
From: Geoff Levand @ 2008-02-08 22:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080208224723.029462363@am.sony.com>
PS3 firmware 1.94 added the source of power and reset events to the
payload of the system manager POWER_PRESSED and RESET_PRESSED events.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/ps3/ps3-sys-manager.c | 29 +++++++++++++++++++++++------
1 file changed, 23 insertions(+), 6 deletions(-)
--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -138,9 +138,11 @@ enum ps3_sys_manager_attr {
/**
* enum ps3_sys_manager_event - External event type, reported by system manager.
- * @PS3_SM_EVENT_POWER_PRESSED: payload.value not used.
+ * @PS3_SM_EVENT_POWER_PRESSED: payload.value =
+ * enum ps3_sys_manager_button_event.
* @PS3_SM_EVENT_POWER_RELEASED: payload.value = time pressed in millisec.
- * @PS3_SM_EVENT_RESET_PRESSED: payload.value not used.
+ * @PS3_SM_EVENT_RESET_PRESSED: payload.value =
+ * enum ps3_sys_manager_button_event.
* @PS3_SM_EVENT_RESET_RELEASED: payload.value = time pressed in millisec.
* @PS3_SM_EVENT_THERMAL_ALERT: payload.value = thermal zone id.
* @PS3_SM_EVENT_THERMAL_CLEARED: payload.value = thermal zone id.
@@ -158,6 +160,17 @@ enum ps3_sys_manager_event {
};
/**
+ * enum ps3_sys_manager_button_event - Button event payload values.
+ * @PS3_SM_BUTTON_EVENT_HARD: Hardware generated event.
+ * @PS3_SM_BUTTON_EVENT_SOFT: Software generated event.
+ */
+
+enum ps3_sys_manager_button_event {
+ PS3_SM_BUTTON_EVENT_HARD = 0,
+ PS3_SM_BUTTON_EVENT_SOFT = 1,
+};
+
+/**
* enum ps3_sys_manager_next_op - Operation to perform after lpar is destroyed.
*/
@@ -416,8 +429,10 @@ static int ps3_sys_manager_handle_event(
switch (event.type) {
case PS3_SM_EVENT_POWER_PRESSED:
- dev_dbg(&dev->core, "%s:%d: POWER_PRESSED\n",
- __func__, __LINE__);
+ dev_dbg(&dev->core, "%s:%d: POWER_PRESSED (%s)\n",
+ __func__, __LINE__,
+ (event.value == PS3_SM_BUTTON_EVENT_SOFT ? "soft"
+ : "hard"));
ps3_sm_force_power_off = 1;
/*
* A memory barrier is use here to sync memory since
@@ -432,8 +447,10 @@ static int ps3_sys_manager_handle_event(
__func__, __LINE__, event.value);
break;
case PS3_SM_EVENT_RESET_PRESSED:
- dev_dbg(&dev->core, "%s:%d: RESET_PRESSED\n",
- __func__, __LINE__);
+ dev_dbg(&dev->core, "%s:%d: RESET_PRESSED (%s)\n",
+ __func__, __LINE__,
+ (event.value == PS3_SM_BUTTON_EVENT_SOFT ? "soft"
+ : "hard"));
ps3_sm_force_power_off = 0;
/*
* A memory barrier is use here to sync memory since
--
^ permalink raw reply
* [patch 4/6] PS3: Use system reboot on restart
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080208224723.029462363@am.sony.com>
The PS3 Other OS boot flag is not checked when an LPAR reboot is done,
so the ps3-boot-game-os utility fails to reboot the system into the
Game OS. This fix changes the PS3 restart handler from requesting an
PS3_SM_NEXT_OP_LPAR_REBOOT to requesting an PS3_SM_NEXT_OP_SYS_REBOOT.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/ps3/ps3-sys-manager.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/ps3/ps3-sys-manager.c
+++ b/drivers/ps3/ps3-sys-manager.c
@@ -622,7 +622,7 @@ static void ps3_sys_manager_final_restar
ps3_vuart_cancel_async(dev);
ps3_sys_manager_send_attr(dev, 0);
- ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_LPAR_REBOOT,
+ ps3_sys_manager_send_next_op(dev, PS3_SM_NEXT_OP_SYS_REBOOT,
PS3_SM_WAKE_DEFAULT);
ps3_sys_manager_send_request_shutdown(dev);
--
^ permalink raw reply
* [patch 3/6] PS3: Fix bootwrapper hang bug
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20080208224723.029462363@am.sony.com>
Fix a bug in the lv1_get_repository_node_value() routine of the PS3
bootwrapper. Changes in the PS3 system firmware 2.20 cause this bug
to hang the system when branching from the bootwrapper to the kernel
_start.
Since the video system has not yet been enabled at the time
the bug is hit, the system hangs with a blank screen. Earlier
firmwares don't cause such a catastrophic failure, and so this
bug went undetected.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
arch/powerpc/boot/ps3-hvcall.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/powerpc/boot/ps3-hvcall.S
+++ b/arch/powerpc/boot/ps3-hvcall.S
@@ -145,7 +145,7 @@
.macro STORE_REGS_5_2
lwz r11, 16(r1)
std r4, 0(r11)
- lwz r11, 24(r1)
+ lwz r11, 20(r1)
std r5, 0(r11)
.endm
--
^ permalink raw reply
* [patch 2/6] PS3: Fix lpm read pm interval
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Takashi Yamamoto
In-Reply-To: <20080208224723.029462363@am.sony.com>
From: Takashi Yamamoto <TakashiA.Yamamoto@jp.sony.com>
ps3_read_pm (pm_interval) should return an actual HW register value
because the pm_interval register is a counter register.
This patch removes the shadow pm_interval register.
Signed-off-by: Takashi Yamamoto <TakashiA.Yamamoto@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/ps3/ps3-lpm.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
--- a/drivers/ps3/ps3-lpm.c
+++ b/drivers/ps3/ps3-lpm.c
@@ -76,7 +76,6 @@
*
* @pm_control: Shadow of the processor's pm_control register.
* @pm_start_stop: Shadow of the processor's pm_start_stop register.
- * @pm_interval: Shadow of the processor's pm_interval register.
* @group_control: Shadow of the processor's group_control register.
* @debug_bus_control: Shadow of the processor's debug_bus_control register.
*
@@ -91,7 +90,6 @@
struct ps3_lpm_shadow_regs {
u64 pm_control;
u64 pm_start_stop;
- u64 pm_interval;
u64 group_control;
u64 debug_bus_control;
};
@@ -408,7 +406,14 @@ u32 ps3_read_pm(u32 cpu, enum pm_reg_nam
case pm_start_stop:
return lpm_priv->shadow.pm_start_stop;
case pm_interval:
- return lpm_priv->shadow.pm_interval;
+ result = lv1_set_lpm_interval(lpm_priv->lpm_id, 0, 0, &val);
+ if (result) {
+ val = 0;
+ dev_dbg(sbd_core(), "%s:%u: lv1 set_inteval failed: "
+ "reg %u, %s\n", __func__, __LINE__, reg,
+ ps3_result(result));
+ }
+ return (u32)val;
case group_control:
return lpm_priv->shadow.group_control;
case debug_bus_control:
@@ -475,10 +480,8 @@ void ps3_write_pm(u32 cpu, enum pm_reg_n
lpm_priv->shadow.pm_control = val;
break;
case pm_interval:
- if (val != lpm_priv->shadow.pm_interval)
- result = lv1_set_lpm_interval(lpm_priv->lpm_id, val,
- PS3_WRITE_PM_MASK, &dummy);
- lpm_priv->shadow.pm_interval = val;
+ result = lv1_set_lpm_interval(lpm_priv->lpm_id, val,
+ PS3_WRITE_PM_MASK, &dummy);
break;
case pm_start_stop:
if (val != lpm_priv->shadow.pm_start_stop)
@@ -1140,7 +1143,6 @@ int ps3_lpm_open(enum ps3_lpm_tb_type tb
lpm_priv->shadow.pm_control = PS3_LPM_SHADOW_REG_INIT;
lpm_priv->shadow.pm_start_stop = PS3_LPM_SHADOW_REG_INIT;
- lpm_priv->shadow.pm_interval = PS3_LPM_SHADOW_REG_INIT;
lpm_priv->shadow.group_control = PS3_LPM_SHADOW_REG_INIT;
lpm_priv->shadow.debug_bus_control = PS3_LPM_SHADOW_REG_INIT;
--
^ permalink raw reply
* [patch 1/6] PS3: Fix lpm set bookmark
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, Takashi Yamamoto
In-Reply-To: <20080208224723.029462363@am.sony.com>
From: Takashi Yamamoto <TakashiA.Yamamoto@jp.sony.com>
Fix the ps3_set_bookmark() routine of the PS3 logical performance
monitor driver.
To properly set a performance monitor bookmark the Cell processor
requires no instruction branches near the setting of the bookmark
SPR. Testing showed that the use of the db10cyc instruction did
not work correctly. This change replaces the db10cyc instruction
with 10 nop instructions.
Signed-off-by: Takashi Yamamoto <TakashiA.Yamamoto@jp.sony.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/ps3/ps3-lpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/ps3/ps3-lpm.c
+++ b/drivers/ps3/ps3-lpm.c
@@ -181,9 +181,9 @@ void ps3_set_bookmark(u64 bookmark)
* includes cycles before the call.
*/
- asm volatile("or 29, 29, 29;"); /* db10cyc */
+ asm volatile("nop;nop;nop;nop;nop;nop;nop;nop;nop;");
mtspr(SPRN_BKMK, bookmark);
- asm volatile("or 29, 29, 29;"); /* db10cyc */
+ asm volatile("nop;nop;nop;nop;nop;nop;nop;nop;nop;");
}
EXPORT_SYMBOL_GPL(ps3_set_bookmark);
--
^ permalink raw reply
* [patch 0/6] PS3 fixups for 2.6.25
From: Geoff Levand @ 2008-02-08 22:52 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Paul,
Here are a few PS3 fixups to apply for 2.6.25.
[patch 1/6] PS3: Fix lpm set bookmark
[patch 2/6] PS3: Fix lpm read pm interval
[patch 3/6] PS3: Fix bootwrapper hang bug
[patch 4/6] PS3: Use system reboot on restart
[patch 5/6] PS3: Sys-manager code cleanup
[patch 6/6] PS3: Update sys-manager button events
-Geoff
--
^ permalink raw reply
* Re: Leds
From: Grant Likely @ 2008-02-08 19:43 UTC (permalink / raw)
To: Simon Kagstrom; +Cc: Marco Stornelli, LinuxPPC-Embedded
In-Reply-To: <20080208112002.42a15c0d@seasc0532.dyn.rnd.as.sw.ericsson.se>
On Feb 8, 2008 3:20 AM, Simon Kagstrom <simon.kagstrom@ericsson.com> wrote:
> Hi Marco,
>
> On Fri, 08 Feb 2008 11:02:16 +0100
> Marco Stornelli <marco.stornelli@coritel.it> wrote:
>
> > how can specify a led device in a dts file? These leds are connected
> > with gpio to the microprocessor. I can't find anything like a led node
> > in the dts files of the other boards. Have you got any suggestions?
>
> Although I'm not sure if it's the "standard" way, we just added a
> "home-made" node like this:
>
> resetLED@c0018000 {
> device_type = "leds";
> compatible = "reset-leds";
> reg = <c0018000 00008000>;
> };
I've been thinking about this a bit over the last couple of months,
and I think that there is a better way. Since many LEDs are simply
hooked up to GPIO blocks and we're moving towards a common GPIO api
(and device tree binding), I think it would be better to use two
nodes; a node for the gpio block and a node for all the LEDs in the
system. For example (the GPIO dt bindings may differ from my example
here, but you get the gist):
GPIO0: gpio-controller@1418 {
#gpio-cells = <2>;
compatible = "fsl,qe-pario-bank";
reg = <0x1418 0x18>;
gpio-controller;
};
GPIO1: gpio-controller@1460 {
#gpio-cells = <2>;
compatible = "fsl,qe-pario-bank";
reg = <0x1460 0x18>;
gpio-controller;
};
leds@0 {
compatible = "gpio-leds";
led-labels = "led1", "led2", "led3", "led4";
gpios = <&GPIO0 2 0 /* LED1 */
&GPIO0 3 0 /* LED2 */
&GPIO1 8 0 /* LED3 */
&GPIO1 9 0 /* LED4 */
>;
/* More properties are probably needed here to correctly setup
the output levels */
};
Doing it this way means the GPIO block will be usable for more than
just LEDs. Plus once the 'gpio-leds' driver is written leds can be
hooked up almost trivially on new boards.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: APU FPU in Virtex ppc405
From: Grant Likely @ 2008-02-08 19:32 UTC (permalink / raw)
To: A. Nolson; +Cc: linuxppc-embedded
In-Reply-To: <47ACA4BB.6010903@gmail.com>
On Feb 8, 2008 11:51 AM, A. Nolson <alohanono@gmail.com> wrote:
> Hi,
>
> I have just heard that Xilinx has freed the FPU module for the PPC
> architecture in EDK9.2i. WIll I be able to make it work with my
> Secretlab Linux 2.6.24rc3? Will the eldk toolchain for PPC_4xxfp work?
> Will it be just a matter of integrating it with the XPS BSP?I make an
> extensive use of floating point in my applications and this will be
> really useful.
It's been 2 years since I last played with the FPU core. At the time
it wasn't a complete FPU so the eldk 4xxfp toolchain would not work.
I had to build my own. I don't know if the new core is a complete
implementation.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc: fix DEBUG_PREEMPT warning when warning
From: Hugh Dickins @ 2008-02-08 18:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
The powerpc show_regs prints CPU using smp_processor_id: change that to
raw_smp_processor_id, so that when it's showing a WARN_ON backtrace without
preemption disabled, DEBUG_PREEMPT doesn't mess up that warning with its own.
Signed-off-by: Hugh Dickins <hugh@veritas.com>
---
powerpc/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- 2.6.24-git18/arch/powerpc/kernel/process.c 2008-01-24 22:58:37.000000000 +0000
+++ linux/arch/powerpc/kernel/process.c 2008-02-08 12:01:31.000000000 +0000
@@ -462,7 +462,7 @@ void show_regs(struct pt_regs * regs)
current, task_pid_nr(current), current->comm, task_thread_info(current));
#ifdef CONFIG_SMP
- printk(" CPU: %d", smp_processor_id());
+ printk(" CPU: %d", raw_smp_processor_id());
#endif /* CONFIG_SMP */
for (i = 0; i < 32; i++) {
^ permalink raw reply
* [PATCH 3/5] Tsi108_eth: remove not needed code
From: Alexandre Bounine @ 2008-02-08 19:17 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Code clean-up for tsi108_eth network driver.
This patch removes not needed dummy read and the corresponding comment.
The PHY logic requires two reads from the status register to get=20
current link status. This is done correctly inside mii_check_media().=20=20
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
15:47:35.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
15:54:14.000000000 -0500
@@ -297,18 +297,11 @@ static void tsi108_check_phy(struct net_
u32 speed;
unsigned long flags;
=20
- /* Do a dummy read, as for some reason the first read
- * after a link becomes up returns link down, even if
- * it's been a while since the link came up.
- */
-
spin_lock_irqsave(&phy_lock, flags);
=20
if (!data->phy_ok)
goto out;
=20
- tsi108_read_mii(data, MII_BMSR);
-
duplex =3D mii_check_media(&data->mii_if, netif_msg_link(data),
data->init_media);
data->init_media =3D 0;
=20
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 1/5] Tsi108_eth: add missing linking to driver data
From: Alexandre Bounine @ 2008-02-08 19:16 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch adds missing linking to driver data.=20
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-01-24
17:58:37.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
14:30:04.000000000 -0500
@@ -1629,6 +1629,7 @@ tsi108_init_one(struct platform_device *
goto register_fail;
}
=20
+ platform_set_drvdata(pdev, dev);
printk(KERN_INFO "%s: Tsi108 Gigabit Ethernet, MAC: %s\n",
dev->name, print_mac(mac, dev->dev_addr));
#ifdef DEBUG
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 0/5] Tsi108_eth: set of driver fix-ups
From: Alexandre Bounine @ 2008-02-08 19:16 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
This is set of small fixes for Tsi108 Ethernet driver.
Based on kernel version 2.6.24=20
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ permalink raw reply
* [PATCH 2/5] Tsi108_eth: fix detection of 1000Mb mode
From: Alexandre Bounine @ 2008-02-08 19:17 UTC (permalink / raw)
To: jgarzik, netdev; +Cc: linuxppc-dev
Bug fix for tsi108_eth network driver.
This patch fixes a problem with detection of 1000Mb speed.=20
=20=20=20
Signed-off-by: Alexandre Bounine <alexandreb@tundra.com>
---
diff -pNur linux-2.6.24/drivers/net/tsi108_eth.c
linux-2.6.24-fix/drivers/net/tsi108_eth.c
--- linux-2.6.24/drivers/net/tsi108_eth.c 2008-02-06
15:09:19.000000000 -0500
+++ linux-2.6.24-fix/drivers/net/tsi108_eth.c 2008-02-06
15:34:12.000000000 -0500
@@ -1287,6 +1287,7 @@ static void tsi108_init_phy(struct net_d
spin_lock_irqsave(&phy_lock, flags);
}
=20
+ data->mii_if.supports_gmii =3D
mii_check_gmii_support(&data->mii_if);
printk(KERN_DEBUG "PHY_STAT reg contains %08x\n", phyval);
data->phy_ok =3D 1;
data->init_media =3D 1;
@@ -1584,7 +1585,6 @@ tsi108_init_one(struct platform_device *
data->mii_if.phy_id =3D einfo->phy;
data->mii_if.phy_id_mask =3D 0x1f;
data->mii_if.reg_num_mask =3D 0x1f;
- data->mii_if.supports_gmii =3D
mii_check_gmii_support(&data->mii_if);
=20
data->phy =3D einfo->phy;
data->phy_type =3D einfo->phy_type;
---=0D
=0D
Important Notice: This message is intended for the use of the individual to=
whom it is addressed and may contain information which is privileged, conf=
idential and/or exempt from disclosure under applicable law. If the reader =
of this message is not the intended recipient, or is not the employee or ag=
ent responsible for delivering the message to the intended recipient, you a=
re hereby notified that any dissemination, distribution, or copying of this=
communication is strictly prohibited. If you have received this communicat=
ion in error, please notify the sender immediately by telephone or return e=
-mail and delete the original message from your systems. Thank you. =0D
^ 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