* 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: 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: 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: [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
* 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: 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
* 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: [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: [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
* 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: 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
* 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: [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
* 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
* 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
* 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
* 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
* 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: 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
* TFTP timeouts with EmbeddedPlanet 405 board
From: Josh Boyer @ 2006-09-26 15:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I've recently inherited an EmbeddedPlanet 405 Iceplanet eval board and
I'm having trouble getting the bootloader to tftp a kernel. Basically,
pings work, the file appears to be getting correctly served, however the
tftp transfer always times out.
Has anyone else seen this?
josh
^ permalink raw reply
* Re: [PATCH] Lazy interrupt disabling for 64-bit machines
From: Olof Johansson @ 2006-09-26 15:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1159261926.5462.54.camel@localhost.localdomain>
On Tue, 26 Sep 2006 19:12:06 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> 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 :)
You can also get away from doing the mfspr(SPRN_DEC) in
local_irq_enable() by changing the polarity of hard_enabled to
hard_disabled, and have different values for why it was disabled. Saves
an mfspr which can be costly, but adds one instruction (li (n>>8) or
so) in the exception entry path. Not which way that tradeoff will
swing, without benchmarking to show benefit it's just added complexity.
That can be done with a fixed cr too, it just uses two bits instead of
one. There are fewer to take from there though.
-Olof
^ permalink raw reply
* RE: Unable to boot linux on Xilinx ML403 board
From: Mohan Krishna T @ 2006-09-26 15:44 UTC (permalink / raw)
To: 'Grant Likely'; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0609260638t16dae54ct266548030e21ffd1@mail.gmail.com>
The zImage.initrd.elf is of size 3.4MB. I am getting hanged only when I am
using DMA for Ethernet. Booting is going fine when I am using FIFO Mode.
Thanks
Mohan Krishna
-----Original Message-----
From: glikely=40gmail.com =5Bmailto:glikely=40gmail.com=5D On Behalf Of =
Grant Likely
Sent: Tuesday, September 26, 2006 7:09 PM
To: Mohan Krishna T
Cc: Peter Ryser; linuxppc-embedded=40ozlabs.org
Subject: Re: Unable to boot linux on Xilinx ML403 board
On 9/26/06, Mohan Krishna T <tmk=40cmcltd.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?
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely=40secretlab.ca
(403) 399-0195
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: Unable to boot linux on Xilinx ML403 board
From: Grant Likely @ 2006-09-26 15:56 UTC (permalink / raw)
To: Mohan Krishna T; +Cc: linuxppc-embedded
In-Reply-To: <7225230023970127285@unknownmsgid>
On 9/26/06, Mohan Krishna T <tmk@cmcltd.com> wrote:
> The zImage.initrd.elf is of size 3.4MB. I am getting hanged only when I am
> using DMA for Ethernet. Booting is going fine when I am using FIFO Mode.
You may be hitting the 4MB upper limit for zImages. I had the same
problem with slightly smaller images, and it would hang at (seemingly)
random places everytime I changed something. Making the image smaller
made the problem go away.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: Unable to boot linux on Xilinx ML403 board
From: Mohan Krishna T @ 2006-09-26 15:58 UTC (permalink / raw)
To: 'Grant Likely'; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0609260856y69339eb2nb237e53efc2d6de5@mail.gmail.com>
I am using the same image for FIFO mode. It is booting without any problem.
The problem is only coming in DMA mode. Is there any restriction on size if
it is DMA mode? Or should I tale any extra care of RAMDISK if I am in DMA
mode?
Thanks and Regards
Mohan Krishna T
-----Original Message-----
From: glikely=40gmail.com =5Bmailto:glikely=40gmail.com=5D On Behalf Of =
Grant Likely
Sent: Tuesday, September 26, 2006 9:26 PM
To: Mohan Krishna T
Cc: Peter Ryser; linuxppc-embedded=40ozlabs.org
Subject: Re: Unable to boot linux on Xilinx ML403 board
On 9/26/06, Mohan Krishna T <tmk=40cmcltd.com> wrote:
> The zImage.initrd.elf is of size 3.4MB. I am getting hanged only when I am
> using DMA for Ethernet. Booting is going fine when I am using FIFO Mode.
You may be hitting the 4MB upper limit for zImages. I had the same
problem with slightly smaller images, and it would hang at (seemingly)
random places everytime I changed something. Making the image smaller
made the problem go away.
--=20
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely=40secretlab.ca
(403) 399-0195
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: local_irq_save not masking interrupts
From: Scott Wood @ 2006-09-26 16:02 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <451900B0.7010006@cambridgebroadband.com>
Alex Zeffertt wrote:
> 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.
One possibile way (in 2.6.18; I'm assuming 2.6.11 is similar) is that
request_irq() calls setup_irq(), which calls register_irq_proc() and
register_handler_proc(), both of which call proc_mkdir(), which
eventually calls proc_create(), which calls kmalloc() with GFP_KERNEL.
This is probably a bug, since request_irq itself uses GFP_ATOMIC,
indicating an intent for request_irq() to be safely callable in atomic
context.
Can you disable the interrupts at the device level until the handler is
in place, and thus avoid the need to disable IRQs at all?
-Scott
^ 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