* RE: fs_enet - support for SCC on CPM2?
From: Pelton, Dave @ 2006-09-26 15:22 UTC (permalink / raw)
To: Matt Hevern; +Cc: Linuxppc-embedded
> -----Original Message-----
> From: Matt Hevern
<snip>
>=20
> I am trying to compile for an freescale 82xx (CPM2) series=20
> processor, with ethernet on an SCC. (kernel 2.6.x) From what=20
> i can see, in the file drivers/net/fs_enet/fs_enet-main.c,
> the config option "CONFIG_FS_ENET_HAS_SCC" pulls in=20
> "fs_scc_ops" which are defined in=20
> drivers/net/fs_enet/mac-scc.c, but this file does not seem=20
> to have support for 82xx series, failing with various compile errors:
<snip>
> It seems like these errors are mostly due to the driver being tailored
for 8xx series.
<snip>
I had the same problem trying to use fs_enet for 82xx SCC Ethernet and
came to the same conclusion. The FCC could not be used instead of the
SCC because of pin limitations in the hardware design. I ended up using
the "old" SCC Ethernet driver by disabling CONFIG_FS_ENET_HAS_SCC and
enabling CONFIG_SCC_ENET (Under CPM2 options in kernel config). This
does not use the new platform bus structure, and arch/ppc/8260_io/enet.c
may require some board specific tweaks, but it does work.
- David Pelton.
^ permalink raw reply
* Need help to write I2C EEPROM device driver
From: Sachin Rane @ 2006-09-26 14:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6078 bytes --]
Hi,
I am looking for an information to write a device driver to access EEPROM IC M24C02-WBN6.
The EEPROM IC M24C02-WBN is present on the 'ppc440' evaluation board for boot strap purpose.
I have refferred materials available on:
1. some of the material available on www.lm-sensors.org <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org> site
2. Device Driver code for EEPOM IC available on http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013021.html <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013021.html>
3. The documents available in "/usr/src/linux/Documentation/i2c" directory.
4. I2C Drivers, Part I --> http://www.linuxjournal.com/node/7136/print <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.linuxjournal.com/node/7136/print>
I2C Drivers, Part II --> http://www.linuxjournal.com/node/7252/print <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.linuxjournal.com/node/7252/print>
5. Data sheet of IC M24C02-WBN6
6. I2C protocol document (Philips)
But I am not getting a proper link which can help me to write a device driver.
Could you give me answer to my (silly) queries?
Q1. Which way is more appropiate to access a EEPOM chip?
---- a. Accessing through Adapter device driver (adpter driver in turn will acess the chip device driver)
---- b. Or a /dev/ character device file node for the EEPROM IC (by registering a charcter device driver)
As the IC is laying on the I2C bus with the Read (0xA0) and write(0xA1) address, I have to access it through Adapter device driver only.
Q2. As there are two address available for read and Write operation, at which address location the the i2c_probe() will find the device?
Q3. Can I use i2c_smbus_XXXXXXX functions to do interaction with the EEPROM I2C?
---- As per my understanding it should work as SMB is subset of I2C.
Q4. Where I can get the purpose of 'command' argument in 'i2c_smbus_XXXX' functions from 'i2c.h'?
extern s32 i2c_smbus_read_byte_data(struct i2c_client * client, u8 command);
extern s32 i2c_smbus_write_byte_data(struct i2c_client * client, u8 command, u8 value);
extern s32 i2c_smbus_read_word_data(struct i2c_client * client, u8 command);
extern s32 i2c_smbus_write_word_data(struct i2c_client * client, u8 command, u16 value);
extern s32 i2c_smbus_write_block_data(struct i2c_client * client, u8 command, u8 length, u8 *values);
extern s32 i2c_smbus_read_i2c_block_data(struct i2c_client * client, u8 command, u8 *values);
Q4. Is there any guide available on Net for writing a I2C EEMPROM Chip device driver?
Regards,
Sachin Rane
Links that I have gone through:
http://www.lm-sensors.org/browser/lm-sensors/trunk/doc <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/doc>
http://www.lm-sensors.org/browser/lm-sensors/trunk <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk>
http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/developers <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/developers>
http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/chips/adm1024 <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/chips/adm1024>
http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/developers <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/developers>
http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/developers/new_drivers <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/developers/new_drivers>
http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/FAQ <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/FAQ>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/doc <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/doc>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eeprom <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eeprom>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eeprom/ddcmon <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eeprom/ddcmon>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer/24cXX.c <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer/24cXX.c>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer/eeprom.c <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer/eeprom.c>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer/README <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer/README>
http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer/README.eeprom <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/browser/lm-sensors/trunk/prog/eepromer/README.eeprom>
http://www.lm-sensors.org/wiki/Devices <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/wiki/Devices>
http://www.lm-sensors.org/wiki/Documentation <https://mail.alphion.com/exchweb/bin/redir.asp?URL=http://www.lm-sensors.org/wiki/Documentation>
[-- Attachment #2: Type: text/html, Size: 8156 bytes --]
^ permalink raw reply
* Re: [PATCH] Add powerpc get/set_rtc_time interface to new generic rtc class
From: Kumar Gala @ 2006-09-26 14:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1159240397.5462.11.camel@localhost.localdomain>
On Sep 25, 2006, at 10:13 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2006-09-25 at 21:55 -0500, Kim Phillips wrote:
>> Add powerpc get/set_rtc_time interface to new generic rtc class. This
>> abstracts rtc chip specific code from the platform code for rtc-
>> over-i2c
>> platforms. Specific RTC chip support is now configured under
>> Device Drivers -> Real Time Clock. Setting time of day from the RTC
>> on startup is also configurable.
>>
>> Currently, the only default config in powerpc arch is the 8349 itx.
>> Other platforms wanting to consolidate code may also use this.
>>
>> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
>
> I think we should only get that in if we also adapt the various
> platform
> RTC code to be in drivers/rtc ... right now, enabling that option will
> just break everybody.
Maybe just drop the init call for now and let people migrate over to
using this and moving the drivers over to drivers/rtc which aren't
supported there.
- k
>> ---
>> arch/powerpc/kernel/time.c | 44 ++++++++++++++++++++++++++++++++
>> ++++++++++++
>> 1 files changed, 44 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
>> index 7a3c3f7..a231b6d 100644
>> --- a/arch/powerpc/kernel/time.c
>> +++ b/arch/powerpc/kernel/time.c
>> @@ -1048,6 +1048,50 @@ void __init time_init(void)
>> set_dec(tb_ticks_per_jiffy);
>> }
>>
>> +#ifdef CONFIG_RTC_CLASS
>> +int set_rtc_class_time(struct rtc_time *tm)
>> +{
>> + int err;
>> + struct class_device *class_dev =
>> + rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
>> +
>> + if (class_dev == NULL)
>> + return -ENODEV;
>> +
>> + err = rtc_set_time(class_dev, tm);
>> +
>> + rtc_class_close(class_dev);
>> +
>> + return 0;
>> +}
>> +
>> +void get_rtc_class_time(struct rtc_time *tm)
>> +{
>> + int err;
>> + struct class_device *class_dev =
>> + rtc_class_open(CONFIG_RTC_HCTOSYS_DEVICE);
>> +
>> + if (class_dev == NULL)
>> + return;
>> +
>> + err = rtc_read_time(class_dev, tm);
>> +
>> + rtc_class_close(class_dev);
>> +
>> + return;
>> +}
>> +
>> +static int __init rtc_class_hookup(void)
>> +{
>> + ppc_md.get_rtc_time = get_rtc_class_time;
>> + ppc_md.set_rtc_time = set_rtc_class_time;
>> +
>> + return 0;
>> +}
>> +
>> +late_initcall(rtc_class_hookup);
>> +#endif /* CONFIG_RTC_CLASS */
>> +
>>
>> #define FEBRUARY 2
>> #define STARTOFTIME 1970
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Unable to boot linux on Xilinx ML403 board
From: Grant Likely @ 2006-09-26 13:38 UTC (permalink / raw)
To: Mohan Krishna T; +Cc: linuxppc-embedded
In-Reply-To: <7340827822720465792@unknownmsgid>
On 9/26/06, Mohan Krishna T <tmk@cmcltd.com> wrote:
> I have tried the option you have suggested but couldn't boot successfully. I
> tried to debug where exactly the kernel is getting hanged. I could found
> that its hanging in gunzip() function call. It is never coming out of loop
> that decompress the ramdisk image.
How large is you zImage.embedded?
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* CAN driver for Xilinx FX12 ML403
From: linux-ppc @ 2006-09-26 11:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 111 bytes --]
Hello,
Does anybody using some kind of CAN driver working ona Xilinx board like
ML403 ?
Thank you
Massimiliano
[-- Attachment #2: Type: text/html, Size: 279 bytes --]
^ permalink raw reply
* DLPAR fails on SLES9
From: Ingvar Hagelund @ 2006-09-26 10:41 UTC (permalink / raw)
To: linuxppc-dev
I want to do DLPAR to add a virtual network interface (ibmveth) to one
of my LPARS, running Linux. I can't make it work. Note that adding a
physical network interface works without problems.
System: IBM OpenPower 720, managed by HMC
LPAR OS: SLES9, kernel 2.6.5-7.252-pseries64
Installed magical rpms from IBM:
DynamicRM-1.2-0
IBMinvscout-2.2-5
csm.client-1.4.0.12-98
csm.core-1.4.0.12-98
devices.chrp.base.ServiceRM-2.2.0.0-2
diagela-2.1.5-0
evlog-drv-tmpl-0.8-1
librtas-1.3.0-0
lsvpd-0.15.1-1
ppc64-utils-2.5.3-1
rpa-dlpar-1.0-25
rpa-pci-hotplug-1.0-18
rsct.core-2.4.1.2-05070
rsct.core.utils-2.4.1.2-05070
servicelog-0.2.2-0
src-1.2.2.1-05054
I have tried both doing the DLPAR command via the HMC gui, and it's
cli, using this command:
chhwres -r virtualio -m openpower1 -o a \
-p vioserver --rsubtype eth -s 11 \
-a "ieee_virtual_eth=1,port_vlan_id=1,is_trunk=1,\"addl_vlan_ids=690,691,692,693,694,695,696,697,698,699\"" \
-w 5 -d 5
When ran by the hmc cli, I only get this dumb error:
HSCL294C DLPAR ADD Virtual I/O resources failed: HMC adding Virtual I/O ......
HMC Virtual slot DLPAR operation failed. Here are the virtual slot IDs that failed and the reasons for failure:
11 The dynamic logical partitioning operation failed.
The kernel on the lpar logs nothing.
When ran by the hmc gui, I get errors like this in the trace log on the lpar:
# rpttr /var/ct/IW/log/mc/IBM.DRM/trace | perl -ne ' if ( /\|(.+)\|/ ) { $a=$1; $a =~ s/\.+//g; print $a;} ' | perl -pe 's/[^7,^3]8/\n/g;'
C=X(DRM/ C=Xd0
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C44C X`d$Unknown command: ioscl
Gapioscli lsmap -fmt : -plc U9124720656B78F-V1-C43C X`d$Unknown command: ioscl
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C42C X`d$Unknown command: ioscl
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C41C X`Unknown command: ioscl
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C40C X`Unknown command: ioscl
+Ypioscli lsmap -fmt : -plc U9124720656B78F-V1-C39C X`Unknown command: ioscl
{pioscli lsmap -fmt : -plc U9124720656B78F-V1-C38C X`Unknown command: ioscl
>pioscli lsmap -fmt : -plc U9124720656B78F-V1-C37C X`Unknown command: ioscl
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C36C X`Unknown command: ioscl
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C35C X`Unknown command: ioscl
#pioscli lsmap -fmt : -plc U9124720656B78F-V1-C34C X`Unknown command: ioscl
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C33C X`Unknown command: ioscl
/pioscli lsmap -fmt : -plc U9124720656B78F-V1-C32C X`Unknown command: ioscl
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C31C X`Unknown command: ioscl
pioscli lsmap -fmt : -plc U9124720656B78F-V1-C30C X`Unknown command: ioscli
The kernel logs nothing.
Why is it trying to run 'ioscli lsmap'? Isn't that only available for AIX?
I suspect this may be caused by an old hmc version. We run version
4.5.0-20050629.1. Does anyone know if there is a fix for bugs like
this in a later version?
Is it possible to update the HMC, for example to 5.x.something without
updating (read boot) the managed systems as well?
Ingvar Hagelund
Linpro AS
--
When everything fail: Symlink
^ permalink raw reply
* Re: [PATCH] Lazy interrupt disabling for 64-bit machines
From: Gabriel Paubert @ 2006-09-26 10:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1159261926.5462.54.camel@localhost.localdomain>
On Tue, Sep 26, 2006 at 07:12:06PM +1000, Benjamin Herrenschmidt wrote:
>
> > I like it. Got any benchmarks that show a difference?
> >
> > At first glance I found it a bit hard to follow, since the old+new
> > terminology is a bit complicated. There's softe, proc_enabled and
> > hard_enabled. A s/proc_enabled/soft_enabled/g (and similar for
> > asm-offsets) might make it a little more intuitive, since you're
> > touching most uses of it already?
>
> Now think about using -ffixed=crN ... reserve a CR field and use that
> for per-cpu flags like that :)
>
Actually cr5 is never used by GCC on any PPC. Look at the source
code in config/rs6000.h, it is marked fixed and never allocated
as far as I understand.
Regards,
Gabriel "an unused register is a wasted register"
^ permalink raw reply
* Re: local_irq_save not masking interrupts
From: Alex Zeffertt @ 2006-09-26 10:28 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-embedded
In-Reply-To: <995B09A8299C2C44B59866F6391D263516C42D@zch01exm21.fsl.freescale.net>
Liu Dave-r63238 wrote:
> <snip>
>> I'm having a strange problem with interrupts. My platform is
>> the MPC832xEMDS and the BSP I'm using (from Freescale) uses
>> Linux-2.6.11.
>>
>> In the code below I enter a critical section with
>> local_irq_save(), call request_irq() (from
>> mpc832xemds_phy_interrupt_enable) 4 times, then exit the
>> critical section using local_irq_restore.
>>
>> /* Enable interrupts from PHYs */
>> local_irq_save(flags);
>> for (i = 0; i < driver_data->num_phys; i++) {
>> struct atm_dev *dev = driver_data->dev_data[i]->dev;
>> printk("%s/%d\n",__FUNCTION__,__LINE__);
>> RETURN_ON_ERROR(mpc832xemds_phy_interrupt_enable(dev));
>> }
>> local_irq_restore(flags);
>>
>> The problem is that I get an interrupt *before* exiting the
>> critical section. This causes a problem for me, because the
>> interrupts are shared and the correct handler has not yet
>> been registered, so the interrupt never gets deasserted.
>>
>> My question is: why is local_irq_save()/local_irq_restore()
>> not working?
>
> Really? local_irq_save not working?
> I don't believe it.
> Please check if exist any re-enable the interrupt in the critical
> section.
>
> -DAve
Well, mpc832xemds_phy_interrupt_enable() does nothing except call
request_irq(,,SA_SHIRQ,,). I suspect that request_irq() is somehow
reenabling interrupts, but I can't see where it might be doing so.
Is this a possible?
Alex
^ permalink raw reply
* RE: local_irq_save not masking interrupts
From: Liu Dave-r63238 @ 2006-09-26 10:19 UTC (permalink / raw)
To: Alex Zeffertt, linuxppc-embedded
In-Reply-To: <4518FA21.8050801@cambridgebroadband.com>
<snip>
> I'm having a strange problem with interrupts. My platform is=20
> the MPC832xEMDS and the BSP I'm using (from Freescale) uses=20
> Linux-2.6.11.
>=20
> In the code below I enter a critical section with=20
> local_irq_save(), call request_irq() (from=20
> mpc832xemds_phy_interrupt_enable) 4 times, then exit the=20
> critical section using local_irq_restore.
>=20
> /* Enable interrupts from PHYs */
> local_irq_save(flags);
> for (i =3D 0; i < driver_data->num_phys; i++) {
> struct atm_dev *dev =3D driver_data->dev_data[i]->dev;
> printk("%s/%d\n",__FUNCTION__,__LINE__);
> RETURN_ON_ERROR(mpc832xemds_phy_interrupt_enable(dev));
> }
> local_irq_restore(flags);
>=20
> The problem is that I get an interrupt *before* exiting the=20
> critical section. This causes a problem for me, because the=20
> interrupts are shared and the correct handler has not yet=20
> been registered, so the interrupt never gets deasserted.
>=20
> My question is: why is local_irq_save()/local_irq_restore()=20
> not working?
Really? local_irq_save not working?
I don't believe it.=20
Please check if exist any re-enable the interrupt in the critical
section.
-DAve
^ permalink raw reply
* local_irq_save not masking interrupts
From: Alex Zeffertt @ 2006-09-26 10:00 UTC (permalink / raw)
To: linuxppc-embedded
Hi list,
I'm having a strange problem with interrupts. My platform is the
MPC832xEMDS and the BSP I'm using (from Freescale) uses Linux-2.6.11.
In the code below I enter a critical section with local_irq_save(),
call request_irq() (from mpc832xemds_phy_interrupt_enable) 4 times,
then exit the critical section using local_irq_restore.
/* Enable interrupts from PHYs */
local_irq_save(flags);
for (i = 0; i < driver_data->num_phys; i++) {
struct atm_dev *dev = driver_data->dev_data[i]->dev;
printk("%s/%d\n",__FUNCTION__,__LINE__);
RETURN_ON_ERROR(mpc832xemds_phy_interrupt_enable(dev));
}
local_irq_restore(flags);
The problem is that I get an interrupt *before* exiting the critical
section. This causes a problem for me, because the interrupts are
shared and the correct handler has not yet been registered, so the
interrupt never gets deasserted.
My question is: why is local_irq_save()/local_irq_restore() not
working?
TIA,
Alex
^ permalink raw reply
* RE: [RFC][PATCH] QE device tree node definition
From: Li Tony-r64360 @ 2006-09-26 9:57 UTC (permalink / raw)
To: Li Yang-r58472, linuxppc-dev
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D19D680@zch01exm20.fsl.freescale.net>
=20
> -----Original Message-----
> From: Li Yang-r58472=20
> Sent: Tuesday, September 26, 2006 2:24 PM
> To: Li Tony-r64360; linuxppc-dev@ozlabs.org
> Subject: RE: [RFC][PATCH] QE device tree node definition
>=20
> > -----Original Message-----
> > From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> >=20
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org]=20
> On Behalf=20
> > Of Li Tony-r64360
> > Sent: Tuesday, September 26, 2006 10:40 AM
> > To: linuxppc-dev@ozlabs.org
> > Subject: RE: [RFC][PATCH] QE device tree node definition
> >=20
> >=20
> > 1) Where is the QE embedded interrupt controller ?
> > I think the interrupt-parent of the QE function should point to it.
>=20
> QEIC is not necessarily to be defined specifically rather=20
> than using generic interrupt controller spec.
> >=20
> > 2) For the UCC, It is better to make rx-clock and tx-clock=20
> as required=20
> > properties.
> > Almost all functions need this properties
>=20
> Almost is NOT enough to make them required properties for all=20
> UCC functions. There are some devices uses TSA as clock source.
If using TSA, the xx-clock property can use some specific macro to
represent it.
All the UCC need a general clock whether from clocks or TSA.=20
>=20
> - Leo
>=20
^ permalink raw reply
* Re: [PATCH] Lazy interrupt disabling for 64-bit machines
From: Benjamin Herrenschmidt @ 2006-09-26 9:12 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060926011055.32d533e7@pb15>
> I like it. Got any benchmarks that show a difference?
>
> At first glance I found it a bit hard to follow, since the old+new
> terminology is a bit complicated. There's softe, proc_enabled and
> hard_enabled. A s/proc_enabled/soft_enabled/g (and similar for
> asm-offsets) might make it a little more intuitive, since you're
> touching most uses of it already?
Now think about using -ffixed=crN ... reserve a CR field and use that
for per-cpu flags like that :)
Ben.
^ permalink raw reply
* Re: fs_enet - support for SCC on CPM2?
From: Alex Zeffertt @ 2006-09-26 8:40 UTC (permalink / raw)
To: Matt Hevern; +Cc: Linuxppc-embedded
In-Reply-To: <45188E24.1090009@nec.com.au>
Matt Hevern wrote:
>
> Are there any patches/fixes for "fs_enet" for ethernet on SCC for 82xx
> series? - or other options?
>
Are you sure this is what you want to do? Why not use one of the FCCs for
ethernet?
Alex
^ permalink raw reply
* Re: Asterisk on Embedded Linux
From: Armin Schindler @ 2006-09-26 7:21 UTC (permalink / raw)
To: Iwan Koenig; +Cc: Linuxppc-embedded
In-Reply-To: <20060926064451.71706.qmail@web26012.mail.ukl.yahoo.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1134 bytes --]
On Tue, 26 Sep 2006, Iwan Koenig wrote:
> Does anyone known how to compile Asterisk for a
> powerpc-processor?
> I have tryed:
> ./configure --target=powerpc-linux
> --host=powerpc-604-linux-gnu --prefix=/opt/packages
> And it gives following error:
> /root/pwlib/include/ptlib.h... configure: error:
> cannot check for file existence when cross compiling
>
> Ok! I see that it is trying to find the PWLIB-Library.
> Also, i have tryed to compile the pwlib.
> But it didn't work :(. For PWLIB i need the OpenLDAP,
> and when i have compiled the OpenLDAP, than needs
> PWLIB other packages.......
> Also, have anyone ideas, how to compile Asterisk für a
> powerpc-processor with another way?
Which version of Asterisk do you want to use? I have version 1.2.X
cross-compiled, but asterisk sources need to be patched. E.g. the
host tools ar and ranlib are hardcoded in Makefiles.
(I don't know the status for version 1.4).
Armin
--
Armin Schindler <armin.schindler AT sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Asterisk on Embedded Linux
From: Iwan Koenig @ 2006-09-26 6:44 UTC (permalink / raw)
To: Linuxppc-embedded
Does anyone known how to compile Asterisk for a
powerpc-processor?
I have tryed:
./configure --target=powerpc-linux
--host=powerpc-604-linux-gnu --prefix=/opt/packages
And it gives following error:
/root/pwlib/include/ptlib.h... configure: error:
cannot check for file existence when cross compiling
Ok! I see that it is trying to find the PWLIB-Library.
Also, i have tryed to compile the pwlib.
But it didn't work :(. For PWLIB i need the OpenLDAP,
and when i have compiled the OpenLDAP, than needs
PWLIB other packages.......
Also, have anyone ideas, how to compile Asterisk für a
powerpc-processor with another way?
Thanks!!!!
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
^ permalink raw reply
* RE: [RFC][PATCH] QE device tree node definition
From: Li Yang-r58472 @ 2006-09-26 6:23 UTC (permalink / raw)
To: Li Tony-r64360, linuxppc-dev
In-Reply-To: <995B09A8299C2C44B59866F6391D263516C375@zch01exm21.fsl.freescale.net>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of Li
> Tony-r64360
> Sent: Tuesday, September 26, 2006 10:40 AM
> To: linuxppc-dev@ozlabs.org
> Subject: RE: [RFC][PATCH] QE device tree node definition
>=20
>=20
> 1) Where is the QE embedded interrupt controller ?
> I think the interrupt-parent of the QE function should point to it.
QEIC is not necessarily to be defined specifically rather than using
generic interrupt controller spec.
>=20
> 2) For the UCC, It is better to make rx-clock and tx-clock as required
> properties.
> Almost all functions need this properties
Almost is NOT enough to make them required properties for all UCC
functions. There are some devices uses TSA as clock source.
- Leo
^ permalink raw reply
* RE: Unable to boot linux on Xilinx ML403 board
From: Mohan Krishna T @ 2006-09-26 6:14 UTC (permalink / raw)
To: 'Peter Ryser', linuxppc-embedded
In-Reply-To: <451800D9.5010702@xilinx.com>
I have tried the option you have suggested but couldn't boot successfully. I
tried to debug where exactly the kernel is getting hanged. I could found
that its hanging in gunzip() function call. It is never coming out of loop
that decompress the ramdisk image.=20
Any suggestions?=20
Thanks in advance...
Regards
Mohan Krishna T
-----Original Message-----
From: linuxppc-embedded-bounces+tmk=3Dcmcltd.com=40ozlabs.org
=5Bmailto:linuxppc-embedded-bounces+tmk=3Dcmcltd.com=40ozlabs.org=5D On =
Behalf Of
Peter Ryser
Sent: Monday, September 25, 2006 9:46 PM
To: linuxppc-embedded=40ozlabs.org
Subject: Re: Unable to boot linux on Xilinx ML403 board
>avail ram: 00770000 08000000
> =20
>
The ML403 only has 64 MB of RAM, ie. 0x04000000. For a start you can=20
change the amount of memory Linux thinks it has available by adding
mem=3D0x4000000
to the kernel command line like
Linux/PPC load: console=3Dtty1 console=3DttyS0,9600 ip=3Doff =
root=3D/dev/ram=20
rw mem=3D0x4000000
Later, you want to change xparameters*.h in arch/ppc/platforms/xilinx_ocp
- Peter
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded=40ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
DISCLAIMER
=E2=80=9CThe information contained in this e-mail message and/or =
attachments to it may contain confidential or privileged information. If =
you are not the intended recipient, any dissemination, use, review, =
distribution, printing or copying of the information contained in this =
e-mail message and/or attachments to it are strictly prohibited. If you =
have received this communication in error, please notify us by reply =
e-mail or telephone and immediately and permanently delete the message and =
any attachments. Thank you=22=
^ permalink raw reply
* Re: [PATCH] Lazy interrupt disabling for 64-bit machines
From: Olof Johansson @ 2006-09-26 6:10 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17688.45762.294594.33723@cargo.ozlabs.ibm.com>
On Tue, 26 Sep 2006 14:55:30 +1000 Paul Mackerras <paulus@samba.org> wrote:
> This implements a lazy strategy for disabling interrupts. This means
> that local_irq_disable() et al. just clear the 'interrupts are
> enabled' flag in the paca. If an interrupt comes along, the interrupt
> entry code notices that interrupts are supposed to be disabled, and
> clears the EE bit in SRR1, clears the 'interrupts are hard-enabled'
> flag in the paca, and returns. This means that interrupts only
> actually get disabled in the processor when an interrupt comes along.
>
> When interrupts are enabled by local_irq_enable() et al., the code
> sets the interrupts-enabled flag in the paca, and then checks whether
> interrupts got hard-disabled. If so, it also sets the EE bit in the
> MSR to hard-enable the interrupts.
>
> This has the potential to improve performance, and also makes it
> easier to make a kernel that can boot on iSeries and on other 64-bit
> machines, since this lazy-disable strategy is very similar to the
> soft-disable strategy that iSeries already uses.
I like it. Got any benchmarks that show a difference?
At first glance I found it a bit hard to follow, since the old+new
terminology is a bit complicated. There's softe, proc_enabled and
hard_enabled. A s/proc_enabled/soft_enabled/g (and similar for
asm-offsets) might make it a little more intuitive, since you're
touching most uses of it already?
-Olof
^ permalink raw reply
* Re: [POWERPC] iSeries has no legacy I/O
From: Olaf Hering @ 2006-09-26 5:32 UTC (permalink / raw)
To: Olof Johansson; +Cc: Stephen Rothwell, paulus, arnd, ppc-dev
In-Reply-To: <20060926000616.5ece9149@pb15>
On Tue, Sep 26, Olof Johansson wrote:
> This will break floppy and 8042 on platforms that previously did not
> define it and relied on the default being that it was allowed. I'm not
> sure which ones that would be? Getting it in early would give us
> plenty of time to deal with fallout, if any.
chrp32 and prep at least.
^ permalink raw reply
* Re: [PATCH] Lazy interrupt disabling for 64-bit machines
From: Michael Ellerman @ 2006-09-26 5:30 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
In-Reply-To: <17688.45762.294594.33723@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]
On Tue, 2006-09-26 at 14:55 +1000, Paul Mackerras wrote:
> This implements a lazy strategy for disabling interrupts. This means
> that local_irq_disable() et al. just clear the 'interrupts are
> enabled' flag in the paca. If an interrupt comes along, the interrupt
> entry code notices that interrupts are supposed to be disabled, and
> clears the EE bit in SRR1, clears the 'interrupts are hard-enabled'
> flag in the paca, and returns. This means that interrupts only
> actually get disabled in the processor when an interrupt comes along.
I saw this once testing kdump, although I haven't hit it again
(3 retries).
Badness in _local_bh_enable at /home/michael/src/auto/git/kernel/softirq.c:120
Call Trace:
[C000000009F83B60] [C00000000200F810] .show_stack+0x6c/0x1a0 (unreliable)
[C000000009F83C00] [C0000000020219F0] .program_check_exception+0x19c/0x5d0
[C000000009F83CA0] [C0000000020043D0] program_check_common+0xd0/0x100
--- Exception: 700 at ._local_bh_enable+0x34/0x78
LR = .call_do_softirq+0x14/0x24
[C0000000028FF8B0] [C00000000200C4A8] .do_softirq+0x6c/0xb0
[C0000000028FF940] [C00000000204E550] .irq_exit+0x4c/0x64
[C0000000028FF9C0] [C00000000201FC94] .timer_interrupt+0x3c0/0x3fc
[C0000000028FFA90] [C00000000200354C] decrementer_common+0xcc/0x100
--- Exception: 901 at .__delay+0x8/0x24
LR = .__cpu_up+0x118/0x214
[C0000000028FFD80] [C000000002024C80] .__cpu_up+0xfc/0x214 (unreliable)
[C0000000028FFE10] [C00000000206987C] .cpu_up+0xd4/0x164
[C0000000028FFEC0] [C0000000020093A0] .init+0xd4/0x39c
[C0000000028FFF90] [C000000002022F0C] .kernel_thread+0x4c/0x68
Looks like it's hitting the in_irq() warning:
void _local_bh_enable(void)
{
WARN_ON_ONCE(in_irq());
WARN_ON_ONCE(!irqs_disabled());
...
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] Start arch/powerpc/boot code reorganization
From: Segher Boessenkool @ 2006-09-25 23:44 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Matt Porter, Paul Mackerras, linuxppc-dev
In-Reply-To: <4B6C3D97-1872-447A-AEE3-011E0A34298A@kernel.crashing.org>
>>>> All I'm try to say is that "fw,address" is just like the "reg"
>>>> property
>>>> except that it holds the effective addr not the physical addr and
>>>> the
>>>> size of the address is determined by the existence of "/cpus/64-
>>>> bit"
>>>> not #address-cells. That's all.
Oh and use "/cpus/<some-cpu>/64-bit", not a property directly in
the "/cpus" node.
Segher
^ permalink raw reply
* Re: [PATCH 2/7] [POWERPC] The two vio HVC backends clash
From: Olof Johansson @ 2006-09-26 5:10 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20060926133548.43afd711.sfr@canb.auug.org.au>
On Tue, 26 Sep 2006 13:35:48 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> diff --git a/drivers/char/hvc_iseries.c b/drivers/char/hvc_iseries.c
> index 4747729..ea36201 100644
> --- a/drivers/char/hvc_iseries.c
> +++ b/drivers/char/hvc_iseries.c
> @@ -29,6 +29,7 @@ #include <linux/console.h>
> #include <asm/hvconsole.h>
> #include <asm/vio.h>
> #include <asm/prom.h>
> +#include <asm/firmware.h>
> #include <asm/iseries/vio.h>
> #include <asm/iseries/hv_call.h>
> #include <asm/iseries/hv_lp_config.h>
> @@ -493,6 +494,9 @@ static int hvc_vio_init(void)
> atomic_t wait_flag;
> int rc;
>
> + if (!firmware_has_feature(FW_FEATURE_ISERIES))
> + return -EIO;
> +
Shouldn't this be -ENODEV?
-Olof
^ permalink raw reply
* Re: [POWERPC] iSeries has no legacy I/O
From: Olof Johansson @ 2006-09-26 5:06 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus, arnd
In-Reply-To: <20060926135721.50f7f1b0.sfr@canb.auug.org.au>
On Tue, 26 Sep 2006 13:57:21 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> +/*
> + * iSeries has no legacy IO, anything calling this function has to
> + * fail or bad things will happen
> + */
> +static int iseries_check_legacy_ioport(unsigned int baseport)
Ok, I was the third platform that needed this, you're fourth. How about
we just switch the default to assume legacy ioports not being allowed?
This will break floppy and 8042 on platforms that previously did not
define it and relied on the default being that it was allowed. I'm not
sure which ones that would be? Getting it in early would give us
plenty of time to deal with fallout, if any.
Every single platform that lacks legacy ports has to define a dummy
check_legacy_ioport() or else things will blow up since default is
to allow the accesses. Instead, default to legacy io ports not being
supported unless the platform defines the function and returns 0 from it.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: linux-2.6/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/setup.c
+++ linux-2.6/arch/powerpc/platforms/cell/setup.c
@@ -155,15 +155,6 @@ static int __init cell_probe(void)
return 1;
}
-/*
- * Cell has no legacy IO; anything calling this function has to
- * fail or bad things will happen
- */
-static int cell_check_legacy_ioport(unsigned int baseport)
-{
- return -ENODEV;
-}
-
define_machine(cell) {
.name = "Cell",
.probe = cell_probe,
@@ -177,7 +168,6 @@ define_machine(cell) {
.get_rtc_time = rtas_get_rtc_time,
.set_rtc_time = rtas_set_rtc_time,
.calibrate_decr = generic_calibrate_decr,
- .check_legacy_ioport = cell_check_legacy_ioport,
.progress = cell_progress,
.init_IRQ = cell_init_irq,
.pcibios_fixup = cell_pcibios_fixup,
Index: linux-2.6/arch/powerpc/platforms/pasemi/setup.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/pasemi/setup.c
+++ linux-2.6/arch/powerpc/platforms/pasemi/setup.c
@@ -93,12 +93,6 @@ static void __init pas_init_early(void)
pci_direct_iommu_init();
}
-/* No legacy IO on our parts */
-static int pas_check_legacy_ioport(unsigned int baseport)
-{
- return -ENODEV;
-}
-
static __init void pas_init_IRQ(void)
{
struct device_node *np;
@@ -183,6 +177,5 @@ define_machine(pas) {
.halt = pas_halt,
.get_boot_time = pas_get_boot_time,
.calibrate_decr = generic_calibrate_decr,
- .check_legacy_ioport = pas_check_legacy_ioport,
.progress = pas_progress,
};
Index: linux-2.6/arch/powerpc/platforms/powermac/setup.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/setup.c
+++ linux-2.6/arch/powerpc/platforms/powermac/setup.c
@@ -615,14 +615,6 @@ static void __init pmac_init_early(void)
#endif
}
-/*
- * pmac has no legacy IO, anything calling this function has to
- * fail or bad things will happen
- */
-static int pmac_check_legacy_ioport(unsigned int baseport)
-{
- return -ENODEV;
-}
static int __init pmac_declare_of_platform_devices(void)
{
@@ -737,7 +729,6 @@ define_machine(powermac) {
.get_rtc_time = pmac_get_rtc_time,
.calibrate_decr = pmac_calibrate_decr,
.feature_call = pmac_do_feature_call,
- .check_legacy_ioport = pmac_check_legacy_ioport,
.progress = udbg_progress,
#ifdef CONFIG_PPC64
.pci_probe_mode = pmac_pci_probe_mode,
Index: linux-2.6/arch/powerpc/kernel/setup-common.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/setup-common.c
+++ linux-2.6/arch/powerpc/kernel/setup-common.c
@@ -523,8 +523,8 @@ void probe_machine(void)
int check_legacy_ioport(unsigned long base_port)
{
- if (ppc_md.check_legacy_ioport == NULL)
- return 0;
+ if (!ppc_md.check_legacy_ioport)
+ return -ENODEV;
return ppc_md.check_legacy_ioport(base_port);
}
EXPORT_SYMBOL(check_legacy_ioport);
^ permalink raw reply
* [PATCH] Lazy interrupt disabling for 64-bit machines
From: Paul Mackerras @ 2006-09-26 4:55 UTC (permalink / raw)
To: linuxppc-dev
This implements a lazy strategy for disabling interrupts. This means
that local_irq_disable() et al. just clear the 'interrupts are
enabled' flag in the paca. If an interrupt comes along, the interrupt
entry code notices that interrupts are supposed to be disabled, and
clears the EE bit in SRR1, clears the 'interrupts are hard-enabled'
flag in the paca, and returns. This means that interrupts only
actually get disabled in the processor when an interrupt comes along.
When interrupts are enabled by local_irq_enable() et al., the code
sets the interrupts-enabled flag in the paca, and then checks whether
interrupts got hard-disabled. If so, it also sets the EE bit in the
MSR to hard-enable the interrupts.
This has the potential to improve performance, and also makes it
easier to make a kernel that can boot on iSeries and on other 64-bit
machines, since this lazy-disable strategy is very similar to the
soft-disable strategy that iSeries already uses.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index d06f378..157ab40 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -119,6 +119,7 @@ #ifdef CONFIG_PPC64
DEFINE(PACAR1, offsetof(struct paca_struct, saved_r1));
DEFINE(PACATOC, offsetof(struct paca_struct, kernel_toc));
DEFINE(PACAPROCENABLED, offsetof(struct paca_struct, proc_enabled));
+ DEFINE(PACAHARDIRQEN, offsetof(struct paca_struct, hard_enabled));
DEFINE(PACASLBCACHE, offsetof(struct paca_struct, slb_cache));
DEFINE(PACASLBCACHEPTR, offsetof(struct paca_struct, slb_cache_ptr));
DEFINE(PACACONTEXTID, offsetof(struct paca_struct, context.id));
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 2cd872b..0639f1c 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -28,10 +28,6 @@ #include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
#include <asm/cputable.h>
-#ifdef CONFIG_PPC_ISERIES
-#define DO_SOFT_DISABLE
-#endif
-
/*
* System calls.
*/
@@ -90,14 +86,16 @@ system_call_common:
addi r9,r1,STACK_FRAME_OVERHEAD
ld r11,exception_marker@toc(r2)
std r11,-16(r9) /* "regshere" marker */
+ li r10,1
+ stb r10,PACAPROCENABLED(r13)
+ stb r10,PACAHARDIRQEN(r13)
+ std r10,SOFTE(r1)
#ifdef CONFIG_PPC_ISERIES
/* Hack for handling interrupts when soft-enabling on iSeries */
cmpdi cr1,r0,0x5555 /* syscall 0x5555 */
andi. r10,r12,MSR_PR /* from kernel */
crand 4*cr0+eq,4*cr1+eq,4*cr0+eq
beq hardware_interrupt_entry
- lbz r10,PACAPROCENABLED(r13)
- std r10,SOFTE(r1)
#endif
mfmsr r11
ori r11,r11,MSR_EE
@@ -461,8 +459,8 @@ #else /* !CONFIG_PREEMPT */
#endif
restore:
-#ifdef CONFIG_PPC_ISERIES
ld r5,SOFTE(r1)
+#ifdef CONFIG_PPC_ISERIES
cmpdi 0,r5,0
beq 4f
/* Check for pending interrupts (iSeries) */
@@ -479,8 +477,9 @@ #ifdef CONFIG_PPC_ISERIES
bl .do_IRQ
b .ret_from_except_lite /* loop back and handle more */
-4: stb r5,PACAPROCENABLED(r13)
+4:
#endif
+ stb r5,PACAPROCENABLED(r13)
ld r3,_MSR(r1)
andi. r0,r3,MSR_RI
@@ -537,20 +536,15 @@ #ifdef CONFIG_PREEMPT
/* Check that preempt_count() == 0 and interrupts are enabled */
lwz r8,TI_PREEMPT(r9)
cmpwi cr1,r8,0
-#ifdef CONFIG_PPC_ISERIES
ld r0,SOFTE(r1)
cmpdi r0,0
-#else
- andi. r0,r3,MSR_EE
-#endif
crandc eq,cr1*4+eq,eq
bne restore
/* here we are preempting the current task */
1:
-#ifdef CONFIG_PPC_ISERIES
li r0,1
stb r0,PACAPROCENABLED(r13)
-#endif
+ stb r0,PACAHARDIRQEN(r13)
ori r10,r10,MSR_EE
mtmsrd r10,1 /* reenable interrupts */
bl .preempt_schedule
@@ -633,8 +627,7 @@ _GLOBAL(enter_rtas)
/* There is no way it is acceptable to get here with interrupts enabled,
* check it with the asm equivalent of WARN_ON
*/
- mfmsr r6
- andi. r0,r6,MSR_EE
+ lbz r0,PACAPROCENABLED(r13)
1: tdnei r0,0
.section __bug_table,"a"
.llong 1b,__LINE__ + 0x1000000, 1f, 2f
@@ -643,7 +636,13 @@ _GLOBAL(enter_rtas)
1: .asciz __FILE__
2: .asciz "enter_rtas"
.previous
-
+
+ /* Hard-disable interrupts */
+ mfmsr r6
+ rldicl r7,r6,48,1
+ rotldi r7,r7,16
+ mtmsrd r7,1
+
/* Unfortunately, the stack pointer and the MSR are also clobbered,
* so they are saved in the PACA which allows us to restore
* our original state after RTAS returns.
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 3065b47..8981b32 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -34,9 +34,7 @@ #include <asm/hvcall.h>
#include <asm/iseries/lpar_map.h>
#include <asm/thread_info.h>
-#ifdef CONFIG_PPC_ISERIES
#define DO_SOFT_DISABLE
-#endif
/*
* We layout physical memory as follows:
@@ -307,7 +305,9 @@ #define EXCEPTION_PROLOG_COMMON(n, area)
std r9,_LINK(r1); \
mfctr r10; /* save CTR in stackframe */ \
std r10,_CTR(r1); \
+ lbz r10,PACAPROCENABLED(r13); \
mfspr r11,SPRN_XER; /* save XER in stackframe */ \
+ std r10,SOFTE(r1); \
std r11,_XER(r1); \
li r9,(n)+1; \
std r9,_TRAP(r1); /* set trap number */ \
@@ -342,6 +342,34 @@ label##_pSeries: \
EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label##_common)
+#define MASKABLE_EXCEPTION_PSERIES(n, label) \
+ . = n; \
+ .globl label##_pSeries; \
+label##_pSeries: \
+ HMT_MEDIUM; \
+ mtspr SPRN_SPRG1,r13; /* save r13 */ \
+ mfspr r13,SPRN_SPRG3; /* get paca address into r13 */ \
+ std r9,PACA_EXGEN+EX_R9(r13); /* save r9, r10 */ \
+ std r10,PACA_EXGEN+EX_R10(r13); \
+ lbz r10,PACAPROCENABLED(r13); \
+ mfcr r9; \
+ cmpwi r10,0; \
+ beq masked_interrupt; \
+ mfspr r10,SPRN_SPRG1; \
+ std r10,PACA_EXGEN+EX_R13(r13); \
+ std r11,PACA_EXGEN+EX_R11(r13); \
+ std r12,PACA_EXGEN+EX_R12(r13); \
+ clrrdi r12,r13,32; /* get high part of &label */ \
+ mfmsr r10; \
+ mfspr r11,SPRN_SRR0; /* save SRR0 */ \
+ LOAD_HANDLER(r12,label##_common) \
+ ori r10,r10,MSR_IR|MSR_DR|MSR_RI; \
+ mtspr SPRN_SRR0,r12; \
+ mfspr r12,SPRN_SRR1; /* and SRR1 */ \
+ mtspr SPRN_SRR1,r10; \
+ rfid; \
+ b . /* prevent speculative execution */
+
#define STD_EXCEPTION_ISERIES(n, label, area) \
.globl label##_iSeries; \
label##_iSeries: \
@@ -363,25 +391,19 @@ label##_iSeries: \
EXCEPTION_PROLOG_ISERIES_2; \
b label##_common; \
-#ifdef DO_SOFT_DISABLE
+#ifndef CONFIG_PPC_ISERIES
+#define DISABLE_INTS \
+ li r11,0; \
+ stb r11,PACAPROCENABLED(r13); \
+ stb r11,PACAHARDIRQEN(r13)
+#else
#define DISABLE_INTS \
- lbz r10,PACAPROCENABLED(r13); \
li r11,0; \
- std r10,SOFTE(r1); \
mfmsr r10; \
stb r11,PACAPROCENABLED(r13); \
ori r10,r10,MSR_EE; \
mtmsrd r10,1
-
-#define ENABLE_INTS \
- lbz r10,PACAPROCENABLED(r13); \
- mfmsr r11; \
- std r10,SOFTE(r1); \
- ori r11,r11,MSR_EE; \
- mtmsrd r11,1
-
-#else /* hard enable/disable interrupts */
-#define DISABLE_INTS
+#endif
#define ENABLE_INTS \
ld r12,_MSR(r1); \
@@ -389,8 +411,6 @@ #define ENABLE_INTS \
rlwimi r11,r12,0,MSR_EE; \
mtmsrd r11,1
-#endif
-
#define STD_EXCEPTION_COMMON(trap, label, hdlr) \
.align 7; \
.globl label##_common; \
@@ -531,11 +551,11 @@ #endif /* __DISABLED__ */
mfspr r12,SPRN_SRR1 /* and SRR1 */
b .slb_miss_realmode /* Rel. branch works in real mode */
- STD_EXCEPTION_PSERIES(0x500, hardware_interrupt)
+ MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt)
STD_EXCEPTION_PSERIES(0x600, alignment)
STD_EXCEPTION_PSERIES(0x700, program_check)
STD_EXCEPTION_PSERIES(0x800, fp_unavailable)
- STD_EXCEPTION_PSERIES(0x900, decrementer)
+ MASKABLE_EXCEPTION_PSERIES(0x900, decrementer)
STD_EXCEPTION_PSERIES(0xa00, trap_0a)
STD_EXCEPTION_PSERIES(0xb00, trap_0b)
@@ -587,7 +607,24 @@ #endif /* CONFIG_CBE_RAS */
/*** pSeries interrupt support ***/
/* moved from 0xf00 */
- STD_EXCEPTION_PSERIES(., performance_monitor)
+ MASKABLE_EXCEPTION_PSERIES(., performance_monitor)
+
+/*
+ * An interrupt came in while soft-disabled; clear EE in SRR1,
+ * clear paca->hard_enabled and return.
+ */
+masked_interrupt:
+ stb r10,PACAHARDIRQEN(r13)
+ mtcrf 0x80,r9
+ ld r9,PACA_EXGEN+EX_R9(r13)
+ mfspr r10,SPRN_SRR1
+ rldicl r10,r10,48,1 /* clear MSR_EE */
+ rotldi r10,r10,16
+ mtspr SPRN_SRR1,r10
+ ld r10,PACA_EXGEN+EX_R10(r13)
+ mfspr r13,SPRN_SPRG1
+ rfid
+ b .
.align 7
_GLOBAL(do_stab_bolted_pSeries)
@@ -942,7 +979,8 @@ #endif
REST_8GPRS(2, r1)
mfmsr r10
- clrrdi r10,r10,2 /* clear RI (LE is 0 already) */
+ rldicl r10,r10,48,1 /* clear EE */
+ rldicr r10,r10,16,61 /* clear RI (LE is 0 already) */
mtmsrd r10,1
mtspr SPRN_SRR1,r12
@@ -1860,8 +1898,11 @@ _GLOBAL(__secondary_start)
/* enable MMU and jump to start_secondary */
LOAD_REG_ADDR(r3, .start_secondary_prolog)
LOAD_REG_IMMEDIATE(r4, MSR_KERNEL)
-#ifdef DO_SOFT_DISABLE
+#ifdef CONFIG_PPC_ISERIES
ori r4,r4,MSR_EE
+#else
+ stb r7,PACAPROCENABLED(r13)
+ stb r7,PACAHARDIRQEN(r13)
#endif
mtspr SPRN_SRR0,r3
mtspr SPRN_SRR1,r4
@@ -1999,9 +2040,11 @@ _STATIC(start_here_common)
/* Load up the kernel context */
5:
-#ifdef DO_SOFT_DISABLE
li r5,0
stb r5,PACAPROCENABLED(r13) /* Soft Disabled */
+#ifndef CONFIG_PPC_ISERIES
+ stb r5,PACAHARDIRQEN(r13) /* hard-disabled too */
+#else
mfmsr r5
ori r5,r5,MSR_EE /* Hard Enabled */
mtmsrd r5
diff --git a/arch/powerpc/kernel/idle_power4.S b/arch/powerpc/kernel/idle_power4.S
index 30de81d..2eac58d 100644
--- a/arch/powerpc/kernel/idle_power4.S
+++ b/arch/powerpc/kernel/idle_power4.S
@@ -30,6 +30,13 @@ END_FTR_SECTION_IFCLR(CPU_FTR_CAN_NAP)
beqlr
/* Go to NAP now */
+ mfmsr r7
+ rldicl r0,r7,48,1
+ rotldi r0,r0,16
+ mtmsrd r0,1 /* hard-disable interrupts */
+ li r0,1
+ stb r0,PACAPROCENABLED(r13) /* we'll hard-enable shortly */
+ stb r0,PACAHARDIRQEN(r13)
BEGIN_FTR_SECTION
DSSALL
sync
@@ -38,7 +45,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
ld r8,TI_LOCAL_FLAGS(r9) /* set napping bit */
ori r8,r8,_TLF_NAPPING /* so when we take an exception */
std r8,TI_LOCAL_FLAGS(r9) /* it will return to our caller */
- mfmsr r7
ori r7,r7,MSR_EE
oris r7,r7,MSR_POW@h
1: sync
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index b443233..efbd77a 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -95,6 +95,20 @@ #ifdef CONFIG_PPC64
EXPORT_SYMBOL(irq_desc);
int distribute_irqs = 1;
+
+#ifndef CONFIG_PPC_ISERIES
+void local_irq_restore(unsigned long en)
+{
+ get_paca()->proc_enabled = en;
+ if (!en || get_paca()->hard_enabled)
+ return;
+ /* need to hard-enable interrupts here */
+ get_paca()->hard_enabled = en;
+ if ((int)mfspr(SPRN_DEC) < 0)
+ mtspr(SPRN_DEC, 1);
+ hard_irq_enable();
+}
+#endif /* CONFIG_PPC_ISERIES */
#endif /* CONFIG_PPC64 */
int show_interrupts(struct seq_file *p, void *v)
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index 807193a..9179f07 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -49,6 +49,10 @@ #ifdef CONFIG_8xx
#include <asm/commproc.h>
#endif
+#ifdef CONFIG_PPC64
+EXPORT_SYMBOL(local_irq_restore);
+#endif
+
#ifdef CONFIG_PPC32
extern void transfer_to_handler(void);
extern void do_IRQ(struct pt_regs *regs);
diff --git a/arch/powerpc/platforms/iseries/ksyms.c b/arch/powerpc/platforms/iseries/ksyms.c
index a220084..2430848 100644
--- a/arch/powerpc/platforms/iseries/ksyms.c
+++ b/arch/powerpc/platforms/iseries/ksyms.c
@@ -19,9 +19,3 @@ EXPORT_SYMBOL(HvCall4);
EXPORT_SYMBOL(HvCall5);
EXPORT_SYMBOL(HvCall6);
EXPORT_SYMBOL(HvCall7);
-
-#ifdef CONFIG_SMP
-EXPORT_SYMBOL(local_get_flags);
-EXPORT_SYMBOL(local_irq_disable);
-EXPORT_SYMBOL(local_irq_restore);
-#endif
diff --git a/arch/powerpc/platforms/iseries/misc.S b/arch/powerpc/platforms/iseries/misc.S
index 7641fc7..385a627 100644
--- a/arch/powerpc/platforms/iseries/misc.S
+++ b/arch/powerpc/platforms/iseries/misc.S
@@ -19,18 +19,6 @@ #include <asm/ppc_asm.h>
.text
-/* unsigned long local_save_flags(void) */
-_GLOBAL(local_get_flags)
- lbz r3,PACAPROCENABLED(r13)
- blr
-
-/* unsigned long local_irq_disable(void) */
-_GLOBAL(local_irq_disable)
- lbz r3,PACAPROCENABLED(r13)
- li r4,0
- stb r4,PACAPROCENABLED(r13)
- blr /* Done */
-
/* void local_irq_restore(unsigned long flags) */
_GLOBAL(local_irq_restore)
lbz r5,PACAPROCENABLED(r13)
diff --git a/include/asm-powerpc/hw_irq.h b/include/asm-powerpc/hw_irq.h
index d403592..66cc2ac 100644
--- a/include/asm-powerpc/hw_irq.h
+++ b/include/asm-powerpc/hw_irq.h
@@ -7,15 +7,28 @@ #define _ASM_POWERPC_HW_IRQ_H
#ifdef __KERNEL__
#include <linux/errno.h>
+#include <linux/compiler.h>
#include <asm/ptrace.h>
#include <asm/processor.h>
extern void timer_interrupt(struct pt_regs *);
-#ifdef CONFIG_PPC_ISERIES
+#ifdef CONFIG_PPC64
+#include <asm/paca.h>
+
+static inline unsigned long local_get_flags(void)
+{
+ return get_paca()->proc_enabled;
+}
+
+static inline unsigned long local_irq_disable(void)
+{
+ unsigned long flag = get_paca()->proc_enabled;
+ get_paca()->proc_enabled = 0;
+ barrier();
+ return flag;
+}
-extern unsigned long local_get_flags(void);
-extern unsigned long local_irq_disable(void);
extern void local_irq_restore(unsigned long);
#define local_irq_enable() local_irq_restore(1)
@@ -24,17 +37,14 @@ #define local_irq_save(flags) ((flags) =
#define irqs_disabled() (local_get_flags() == 0)
+#define hard_irq_enable() __mtmsrd(mfmsr() | MSR_EE, 1)
+#define hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
+
#else
#if defined(CONFIG_BOOKE)
#define SET_MSR_EE(x) mtmsr(x)
#define local_irq_restore(flags) __asm__ __volatile__("wrtee %0" : : "r" (flags) : "memory")
-#elif defined(__powerpc64__)
-#define SET_MSR_EE(x) __mtmsrd(x, 1)
-#define local_irq_restore(flags) do { \
- __asm__ __volatile__("": : :"memory"); \
- __mtmsrd((flags), 1); \
-} while(0)
#else
#define SET_MSR_EE(x) mtmsr(x)
#define local_irq_restore(flags) mtmsr(flags)
@@ -81,7 +91,7 @@ #define local_save_flags(flags) ((flags)
#define local_irq_save(flags) local_irq_save_ptr(&flags)
#define irqs_disabled() ((mfmsr() & MSR_EE) == 0)
-#endif /* CONFIG_PPC_ISERIES */
+#endif /* CONFIG_PPC64 */
#define mask_irq(irq) \
({ \
diff --git a/include/asm-powerpc/paca.h b/include/asm-powerpc/paca.h
index 0a4e5c9..9ef277e 100644
--- a/include/asm-powerpc/paca.h
+++ b/include/asm-powerpc/paca.h
@@ -94,6 +94,7 @@ #endif /* CONFIG_PPC_ISERIES */
u64 saved_r1; /* r1 save for RTAS calls */
u64 saved_msr; /* MSR saved here by enter_rtas */
u8 proc_enabled; /* irq soft-enable flag */
+ u8 hard_enabled; /* set if irqs are enabled in MSR */
u8 io_sync; /* writel() needs spin_unlock sync */
/* Stuff for accurate time accounting */
^ permalink raw reply related
* [POWERPC] iSeries has no legacy I/O
From: Stephen Rothwell @ 2006-09-26 3:57 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/setup.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/platforms/iseries/setup.c b/arch/powerpc/platforms/iseries/setup.c
index 7cb6b5f..a0ff7ba 100644
--- a/arch/powerpc/platforms/iseries/setup.c
+++ b/arch/powerpc/platforms/iseries/setup.c
@@ -649,6 +649,15 @@ #ifndef CONFIG_PCI
void __init iSeries_init_IRQ(void) { }
#endif
+/*
+ * iSeries has no legacy IO, anything calling this function has to
+ * fail or bad things will happen
+ */
+static int iseries_check_legacy_ioport(unsigned int baseport)
+{
+ return -ENODEV;
+}
+
static int __init iseries_probe(void)
{
unsigned long root = of_get_flat_dt_root();
@@ -677,6 +686,7 @@ define_machine(iseries) {
.calibrate_decr = generic_calibrate_decr,
.progress = iSeries_progress,
.probe = iseries_probe,
+ .check_legacy_ioport = iseries_check_legacy_ioport,
/* XXX Implement enable_pmcs for iSeries */
};
--
1.4.2.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox