* [PATCH] via-mpu: compile without Power Management support
From: Kristian Mueller @ 2005-12-15 3:45 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 77 bytes --]
Don't check for sleep_in_progress if there is no
Power Management support.
[-- Attachment #2: pmu-without-pm.patch --]
[-- Type: text/x-patch, Size: 817 bytes --]
--- linux/drivers/macintosh/via-pmu.c.orig 2005-12-15 11:28:28.000000000 +0800
+++ linux/drivers/macintosh/via-pmu.c 2005-12-15 10:04:53.000000000 +0800
@@ -2911,8 +2911,10 @@ pmu_ioctl(struct inode * inode, struct f
* the fbdev
*/
case PMU_IOC_GET_BACKLIGHT:
+#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
if (sleep_in_progress)
return -EBUSY;
+#endif /* CONFIG_PM && CONFIG_PPC32 */
error = get_backlight_level();
if (error < 0)
return error;
@@ -2920,8 +2922,10 @@ pmu_ioctl(struct inode * inode, struct f
case PMU_IOC_SET_BACKLIGHT:
{
__u32 value;
+#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
if (sleep_in_progress)
return -EBUSY;
+#endif /* CONFIG_PM && CONFIG_PPC32 */
error = get_user(value, argp);
if (!error)
error = set_backlight_level(value);
^ permalink raw reply
* Help: mcc driver for mpc8260
From: s.maiti @ 2005-12-15 3:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: omanakuttan
In-Reply-To: <20051215010004.87ACF6887E@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
Dear all,
I have downloaded the souce code of mcc for 8260 from sourceforge website.
I will be highly grateful to you people if you can clear my confusion
regarding the mcc driver for mpc8260:
1) What I have to do if I want to use all 128 channels to route through
TDM B of mcc1?
2) What will be the SI RAM & SI Mode Registers contents?
3) What will be the content of MCCF1?
Thanks in advance........
Souvik Maiti
Tata Consultancy Services Limited
Bengal Intelligent Park
Bldg. - D, Plots - A2, M2 & N2
Block - GP, Sector V
Salt Lake Electronics Complex
Kolkata - 700091, West Bengal
India
Mailto: s.maiti@tcs.com
Website: http://www.tcs.com
Notice: The 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
[-- Attachment #2: Type: text/html, Size: 1649 bytes --]
^ permalink raw reply
* Re: [PATCH] via-mpu: compile without Power Management support
From: Olof Johansson @ 2005-12-15 4:14 UTC (permalink / raw)
To: Kristian Mueller; +Cc: linuxppc-dev
In-Reply-To: <1134618322.4972.10.camel@pismo>
On Thu, Dec 15, 2005 at 11:45:22AM +0800, Kristian Mueller wrote:
> Don't check for sleep_in_progress if there is no
> Power Management support.
Creeping #ifdeffing, not good.
Please move the sleep_in_progress variable outside of #ifdef where it's
defined instead, it will default to 0 and never trigger, but things will
still build.
-Olof
^ permalink raw reply
* RE: Linuxppc-embedded Digest, Vol 16, Issue 36
From: KS Soumya-ask067 @ 2005-12-15 4:27 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Is there anything more specific that I need to do to enable my PCI =
window to 512MB? I'm using Linux kernel 2.4.20 / KO2.6.10 with MPC8540 =
ADS defconfig and U-Boot for the same. By default, the U-Boot is =
specifying a window of 256MB (0x80000000 - 0x8fffffff). Even if the =
Linux specifies 512MB (0x80000000 - 0x9fffffff), I am not able to access =
my device registers on 9f4f0000 (BAR of my device).=20
But if I specify in U-Boot to make the PCI window as 512MB, (or if I =
make the Linux to hold 256MB) then Im able to access my device. What =
should I do for my kernel not to be dependent on U-Boot for the same?=20
Any pointers would be of great help. Thank you.
-Soumya
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of =
linuxppc-embedded-request@ozlabs.org
Sent: Wednesday, December 14, 2005 8:01 PM
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 16, Issue 36
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific than =
"Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. Re: how to define BASE_BAUD (Debora Liu)
2. "make xconfig" error (2.4.25 devel) (HappyPhot)
3. Re: MPC8245 with its internal UART (HappyPhot)
4. SPI driver for 82xx (Dmytro Bablinyuk)
5. Re: pq2_find_bridges hangs system (Alex BASTOS)
6. Re: pq2_find_bridges hangs system (Vitaly Bordug)
7. [SOLVED] Re: pq2_find_bridges hangs system (Alex BASTOS)
8. Re: [SOLVED] Re: pq2_find_bridges hangs system (Vitaly Bordug)
9. 8260 ethernet driver multicast problem (Robin Mathew)
10. Re: [SOLVED] Re: pq2_find_bridges hangs system (Kumar Gala)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Dec 2005 09:39:32 +0800
From: "Debora Liu" <deboralh@fel.com.cn>
Subject: Re: how to define BASE_BAUD
To: "HappyPhot" <happyphot@gmail.com>
Cc: Linuxppc-embedded <Linuxppc-embedded@ozlabs.org>
Message-ID: <200512140929125.SM00772@RavProxy>
Hello, HappyPhot
In message <2005-12-14 01:19:49 happyphot@gmail.com> you wrote:
> Can anybody tell me how to define the "BASE_BAUD" value for the=20
>"struct serial_state rs_table[]" ?
> It seems has different value for each platform !!
yes, this is different for each platform.
see your crystal used by UART.
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Debora Liu
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1deboralh@fel.com.cn
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12005-12-14
------------------------------
Message: 2
Date: Wed, 14 Dec 2005 11:41:45 +0800
From: "HappyPhot" <happyphot@gmail.com>
Subject: "make xconfig" error (2.4.25 devel)
To: <linuxppc-embedded@ozlabs.org>
Message-ID: <000401c60063$3dc46040$0760120a@photon>
Content-Type: text/plain; format=3Dflowed; charset=3D"big5";
reply-type=3Doriginal
Hello,
I am trying "linuxppc_2_4_devel-2005-10-25-1440".
The "make xconfig" seems not work. ("make menuconfig" is ok) It shows :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
....
./tkparse < ../arch/ppc/config.in >> kconfig.tk
arch/ppc/8xx_io/Config.in: 312: unknown define_bool value
make[1]: *** [kconfig.tk] Error 1
....
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Does this version support "make xconfig" ?
thank you,
/HappyPhot
------------------------------
Message: 3
Date: Wed, 14 Dec 2005 14:36:10 +0800
From: "HappyPhot" <happyphot@gmail.com>
Subject: Re: MPC8245 with its internal UART
To: <hs@denx.de>, <linuxppc-embedded@ozlabs.org>
Message-ID: <005301c60078$b8dd1550$0760120a@photon>
Content-Type: text/plain; format=3Dflowed; charset=3D"iso-8859-1";
reply-type=3Doriginal
Hi,
I've tried this (CPC45_config) on Denx Kernel 2.4.25, and my serial =
console works now. Thank you very much.
Is there any similar platform for kernel 2.6 ? (i.e. MPC8245 with its =
internal UART )
thank you,
/HappyPhot
>=20
>> Who can tell me which flatform is similar to mine ? I've tried "make=20
>> sandpoint_defconfig", but seems not the right one.
>=20
> If you want to use Linux 2.4.25, you can try CPC45_defconfig from the=20
> Denx Kernel ...
------------------------------
Message: 4
Date: Wed, 14 Dec 2005 18:13:02 +1100
From: Dmytro Bablinyuk <dmytro.bablinyuk@rftechnology.com.au>
Subject: SPI driver for 82xx
To: linuxppc-embedded <Linuxppc-embedded@ozlabs.org>
Message-ID: <439FC5FE.8090703@rftechnology.com.au>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
Is anywhere available SPI driver (SPI peripheral) for 82xx for 2.6.x =
kernel?
I will appreciate any reference or suggestion.
Thank you
Dmytro
------------------------------
Message: 5
Date: Wed, 14 Dec 2005 11:21:02 +0100
From: Alex BASTOS <alebas@televes.com>
Subject: Re: pq2_find_bridges hangs system
To: Alex BASTOS <alebas@televes.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Message-ID: <1134555662.439ff20e6e812@webmail.televes.com:443>
Content-Type: text/plain; charset=3DISO-8859-15
Vitaly,
So, I have arrived to some conclusions.
1) With my previous kernel version (2.6.11) I had no problems because it =
had CONFIG_PCI_8260 and CONFIG_PPC_INDIRECT_PCI unset.
So I think no effective read/write operation was executed, and so that, =
no Machine Check.
In fact, this is the configuration I would prefer for my board. I have =
to set CONFIG_PCI for enabling USB, but I don't want all the HW stuff of =
the PCI. I can get these also with 2.6.15 if I modify Kconfig, to allow =
me to unset PCI_8260 (and then PPC_INDIRECT_PCI) for my board.
With that, the problem dissapears and I can boot 2.6.15.
Shouldn't this (PCI_8260) be visible from xconfig for those like me who =
wants USB (=3D> CONFIG_PCI) but don't really have any PCI device?
2) Although I am using Uboot 1.1.4, it is not top of git. I have found =
your changes to support PCI on 8272ADS for u-boot are not still applied =
on the version i am using. So, could this be causing the problem? Is =
there any configuration done in u-boot required by the PCI on the linux =
kernel to boot (BR3,OR3, EMR, ...)?
I should say that, on ADS, I have an older version of u-boot, 1.1.2, and =
it boots OK.
3) I have seen that from u-boot, a reset occurs when I read Internal =
Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same =
all PCI section on IM becomes zero. Is this a known behaviour? May this =
reflect a hardware problem?
In conclusion, 1) solves my "must", a working board (without PCI).
But I still would like to know what am I doing so wrong with this.
Best regards,
Alex
Citando Alex BASTOS <alebas@televes.com>:
> Vitaly,
>
> It didn't work. So I will check pq2ads_setup_pci to check if some=20
> board specific issue is affected.
>
> I will say you if I find anything
>
> Thanks
>
> Alex.
>
------------------------------
Message: 6
Date: Wed, 14 Dec 2005 14:29:34 +0300
From: Vitaly Bordug <vbordug@ru.mvista.com>
Subject: Re: pq2_find_bridges hangs system
To: Alex BASTOS <alebas@televes.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Message-ID: <43A0021E.7030406@ru.mvista.com>
Content-Type: text/plain; charset=3DISO-8859-15; format=3Dflowed
Alex BASTOS wrote:
> Vitaly,
>=20
> So, I have arrived to some conclusions.
>=20
> 1) With my previous kernel version (2.6.11) I had no problems because=20
> it had CONFIG_PCI_8260 and CONFIG_PPC_INDIRECT_PCI unset.
> So I think no effective read/write operation was executed, and so=20
> that, no Machine Check.
>=20
> In fact, this is the configuration I would prefer for my board. I have =
> to set CONFIG_PCI for enabling USB, but I don't want all the HW stuff=20
> of the PCI. I can get these also with 2.6.15 if I modify Kconfig, to=20
> allow me to unset PCI_8260 (and then PPC_INDIRECT_PCI) for my board.
> With that, the problem dissapears and I can boot 2.6.15.
>=20
> Shouldn't this (PCI_8260) be visible from xconfig for those like me=20
> who wants USB (=3D> CONFIG_PCI) but don't really have any PCI device?
>=20
Maybe, but I guess more correct is to deal with USB->PCI dependency..=20
Is it really needed(I am not USB expert)?
> 2) Although I am using Uboot 1.1.4, it is not top of git. I have found =
> your changes to support PCI on 8272ADS for u-boot are not still=20
> applied on the version i am using. So, could this be causing the=20
> problem? Is there any configuration done in u-boot required by the PCI =
> on the linux kernel to boot (BR3,OR3, EMR, ...)?
>=20
> I should say that, on ADS, I have an older version of u-boot, 1.1.2,=20
> and it boots OK.
>=20
My changes do not required for kernel to deal with PCI, that patch just =
allows access to PCI in U-Boot. Hence I might be useful if you'll head =
for resolving this issue which I guess unlikely to happen
> 3) I have seen that from u-boot, a reset occurs when I read Internal=20
> Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same=20
> all PCI section on IM becomes zero. Is this a known behaviour? May=20
> this reflect a hardware problem?
>=20
Sounds weird=20
> In conclusion, 1) solves my "must", a working board (without PCI).
> But I still would like to know what am I doing so wrong with this.
>=20
IMHO ability to disable PCI_8260 while PCI is on might be confusing, at =
least for upstream.
> Best regards,
>=20
> Alex
>=20
> Citando Alex BASTOS <alebas@televes.com>:
>=20
>> Vitaly,
>>
>> It didn't work. So I will check pq2ads_setup_pci to check if some=20
>> board specific issue is affected.
>>
>> I will say you if I find anything
>>
>> Thanks
>>
>> Alex.
>>
>=20
>=20
--
Sincerely,
Vitaly
------------------------------
Message: 7
Date: Wed, 14 Dec 2005 15:13:22 +0100
From: Alex BASTOS <alebas@televes.com>
Subject: [SOLVED] Re: pq2_find_bridges hangs system
To: Vitaly Bordug <vbordug@ru.mvista.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Message-ID: <1134569602.43a0288234662@webmail.televes.com:443>
Content-Type: text/plain; charset=3DISO-8859-15
Vitaly,
> Maybe, but I guess more correct is to deal with USB->PCI dependency..
> Is it really needed(I am not USB expert)?
Neither am I. I guess for this Host Controler it is not needed at HW =
level, but I am not sure why it is still required by the SW.
> > 3) I have seen that from u-boot, a reset occurs when I read Internal =
> > Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the=20
> > same all PCI section on IM becomes zero. Is this a known behaviour?=20
> > May this reflect a hardware problem?
> >
> Sounds weird
Here is the problem. The cause for this weird behaviour is that I had =
PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
I had disabled it trying to reduce power compsumption due to the PCI, as =
I am not going to use it. It seems it is not possible that way.
Any idea how to get this done?
> > In conclusion, 1) solves my "must", a working board (without PCI).
> > But I still would like to know what am I doing so wrong with this.
> >
> IMHO ability to disable PCI_8260 while PCI is on might be confusing,=20
> at least for upstream.
You are right.
Thanks so much for your help.
Best regards,
Alex
------------------------------
Message: 8
Date: Wed, 14 Dec 2005 17:14:51 +0300
From: Vitaly Bordug <vbordug@ru.mvista.com>
Subject: Re: [SOLVED] Re: pq2_find_bridges hangs system
To: Alex BASTOS <alebas@televes.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Message-ID: <43A028DB.5090906@ru.mvista.com>
Content-Type: text/plain; charset=3DISO-8859-15; format=3Dflowed
Alex BASTOS wrote:
> Vitaly,
>=20
>> Maybe, but I guess more correct is to deal with USB->PCI dependency..
>> Is it really needed(I am not USB expert)?
>=20
> Neither am I. I guess for this Host Controler it is not needed at HW=20
> level, but I am not sure why it is still required by the SW.
>=20
>=20
>>> 3) I have seen that from u-boot, a reset occurs when I read Internal =
>>> Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the=20
>>> same all PCI section on IM becomes zero. Is this a known behaviour?=20
>>> May this reflect a hardware problem?
>>>
>> Sounds weird
>=20
> Here is the problem. The cause for this weird behaviour is that I had=20
> PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
> I had disabled it trying to reduce power compsumption due to the PCI,=20
> as I am not going to use it. It seems it is not possible that way.
> Any idea how to get this done?
>=20
Well, I guess the best you can do now - just use custom tree. I'll try =
to find good solution for such a case (PCI required by deps but not hw) =
next time I'll touch PCI.
>>> In conclusion, 1) solves my "must", a working board (without PCI).
>>> But I still would like to know what am I doing so wrong with this.
>>>
>> IMHO ability to disable PCI_8260 while PCI is on might be confusing,=20
>> at least for upstream.
>=20
> You are right.
>=20
> Thanks so much for your help.
>=20
> Best regards,
>=20
> Alex
>=20
>=20
--
Sincerely,
Vitaly
------------------------------
Message: 9
Date: Wed, 14 Dec 2005 19:58:40 +0530
From: Robin Mathew <robbinmathew@gmail.com>
Subject: 8260 ethernet driver multicast problem
To: linuxppc-embedded@ozlabs.org
Message-ID:
<5b74ec4d0512140628y42986bc0h2f107e788dd115b6@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"
Hi,
I was encountering a problem with the receipt of multicast packets from =
eth interface in 8260 platform. The issue was traced to the fcc_enet.c =
driver. A stray return in the set_multicast_list function was the =
culprit.
The following is the changes that I have made-
Index: fcc_enet.c
@@ -1488,7 +1488,6 @@
cep =3D (struct fcc_enet_private *)dev->priv;
-return;
/* Get pointer to FCC area in parameter RAM.
*/
ep =3D (fcc_enet_t *)dev->base_addr;
Can you please tell me whether there is any issue with setting the =
driver in multicast or promiscous mode. Was this change deliberately =
done or is it really a bug?
Thanks in advance,
Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: =
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051214/af24a6=
1a/attachment.html
------------------------------
Message: 10
Date: Wed, 14 Dec 2005 08:30:48 -0600
From: Kumar Gala <galak@kernel.crashing.org>
Subject: Re: [SOLVED] Re: pq2_find_bridges hangs system
To: Vitaly Bordug <vbordug@ru.mvista.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>, Alex BASTOS
<alebas@televes.com>
Message-ID: <386A8114-FA1C-44E2-A8F1-CF48F4AF495E@kernel.crashing.org>
Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; =
format=3Dflowed
On Dec 14, 2005, at 8:14 AM, Vitaly Bordug wrote:
> Alex BASTOS wrote:
>> Vitaly,
>>> Maybe, but I guess more correct is to deal with USB->PCI=20
>>> dependency..
>>> Is it really needed(I am not USB expert)?
>> Neither am I. I guess for this Host Controler it is not needed at HW=20
>> level, but I am not sure why it is still required by the SW.
>>>> 3) I have seen that from u-boot, a reset occurs when I read=20
>>>> Internal Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I=20
>>>> do the same all PCI section on IM becomes zero. Is this a known=20
>>>> behaviour?
>>>> May this
>>>> reflect a hardware problem?
>>>>
>>> Sounds weird
>> Here is the problem. The cause for this weird behaviour is that I had =
>> PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
>> I had disabled it trying to reduce power compsumption due to the PCI, =
>> as I am not going to use it. It seems it is not possible that way.
>> Any idea how to get this done?
I'm guessing you dont have anything else doing arbitration on the bus.
- kumar
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 16, Issue 36
*************************************************
^ permalink raw reply
* Re: [PATCH] via-mpu: compile without Power Management support
From: Kristian Mueller @ 2005-12-15 4:31 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20051215041430.GB7468@pb15.lixom.net>
[-- Attachment #1: Type: text/plain, Size: 271 bytes --]
> Please move the sleep_in_progress variable outside of #ifdef where it's
> defined instead, it will default to 0 and never trigger, but things will
> still build.
Okay good point, done.
Fix compilation of via-mpu.c without Power Management support.
Regards,
Kristian
[-- Attachment #2: pmu-without-pm-revised.patch --]
[-- Type: text/x-patch, Size: 493 bytes --]
--- linux/drivers/macintosh/via-pmu.c.orig 2005-12-15 11:28:28.000000000 +0800
+++ linux/drivers/macintosh/via-pmu.c 2005-12-15 12:20:43.000000000 +0800
@@ -157,8 +157,8 @@ static int pmu_version;
static int drop_interrupts;
#if defined(CONFIG_PM) && defined(CONFIG_PPC32)
static int option_lid_wakeup = 1;
-static int sleep_in_progress;
#endif /* CONFIG_PM && CONFIG_PPC32 */
+static int sleep_in_progress;
static unsigned long async_req_locks;
static unsigned int pmu_irq_stats[11];
^ permalink raw reply
* Linux dependency for PCI Window on U-Boot
From: KS Soumya-ask067 @ 2005-12-15 4:54 UTC (permalink / raw)
To: linuxppc-embedded
=20
Hi,
Is there anything more specific that I need to do to enable my PCI =
window to 512MB? I'm using Linux kernel 2.4.20 / KO2.6.10 with MPC8540 =
ADS defconfig and U-Boot for the same. By default, the U-Boot is =
specifying a window of 256MB (0x80000000 - 0x8fffffff). Even if the =
Linux specifies 512MB (0x80000000 - 0x9fffffff), I am not able to access =
my device registers on 9f4f0000 (BAR of my device).=20
But if I specify in U-Boot to make the PCI window as 512MB, (or if I =
make the Linux to hold 256MB) then Im able to access my device. What =
should I do for my kernel not to be dependent on U-Boot for the same?=20
Any pointers would be of great help. Thank you.
-Soumya
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of =
linuxppc-embedded-request@ozlabs.org
Sent: Wednesday, December 14, 2005 8:01 PM
To: linuxppc-embedded@ozlabs.org
Subject: Linuxppc-embedded Digest, Vol 16, Issue 36
Send Linuxppc-embedded mailing list submissions to
linuxppc-embedded@ozlabs.org
To subscribe or unsubscribe via the World Wide Web, visit
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
or, via email, send a message with subject or body 'help' to
linuxppc-embedded-request@ozlabs.org
You can reach the person managing the list at
linuxppc-embedded-owner@ozlabs.org
When replying, please edit your Subject line so it is more specific than =
"Re: Contents of Linuxppc-embedded digest..."
Today's Topics:
1. Re: how to define BASE_BAUD (Debora Liu)
2. "make xconfig" error (2.4.25 devel) (HappyPhot)
3. Re: MPC8245 with its internal UART (HappyPhot)
4. SPI driver for 82xx (Dmytro Bablinyuk)
5. Re: pq2_find_bridges hangs system (Alex BASTOS)
6. Re: pq2_find_bridges hangs system (Vitaly Bordug)
7. [SOLVED] Re: pq2_find_bridges hangs system (Alex BASTOS)
8. Re: [SOLVED] Re: pq2_find_bridges hangs system (Vitaly Bordug)
9. 8260 ethernet driver multicast problem (Robin Mathew)
10. Re: [SOLVED] Re: pq2_find_bridges hangs system (Kumar Gala)
----------------------------------------------------------------------
Message: 1
Date: Wed, 14 Dec 2005 09:39:32 +0800
From: "Debora Liu" <deboralh@fel.com.cn>
Subject: Re: how to define BASE_BAUD
To: "HappyPhot" <happyphot@gmail.com>
Cc: Linuxppc-embedded <Linuxppc-embedded@ozlabs.org>
Message-ID: <200512140929125.SM00772@RavProxy>
Hello, HappyPhot
In message <2005-12-14 01:19:49 happyphot@gmail.com> you wrote:
> Can anybody tell me how to define the "BASE_BAUD" value for the=20
>"struct serial_state rs_table[]" ?
> It seems has different value for each platform !!
yes, this is different for each platform.
see your crystal used by UART.
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1Debora Liu
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1deboralh@fel.com.cn
=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12005-12-14
------------------------------
Message: 2
Date: Wed, 14 Dec 2005 11:41:45 +0800
From: "HappyPhot" <happyphot@gmail.com>
Subject: "make xconfig" error (2.4.25 devel)
To: <linuxppc-embedded@ozlabs.org>
Message-ID: <000401c60063$3dc46040$0760120a@photon>
Content-Type: text/plain; format=3Dflowed; charset=3D"big5";
reply-type=3Doriginal
Hello,
I am trying "linuxppc_2_4_devel-2005-10-25-1440".
The "make xconfig" seems not work. ("make menuconfig" is ok) It shows :
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
....
./tkparse < ../arch/ppc/config.in >> kconfig.tk
arch/ppc/8xx_io/Config.in: 312: unknown define_bool value
make[1]: *** [kconfig.tk] Error 1
....
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Does this version support "make xconfig" ?
thank you,
/HappyPhot
------------------------------
Message: 3
Date: Wed, 14 Dec 2005 14:36:10 +0800
From: "HappyPhot" <happyphot@gmail.com>
Subject: Re: MPC8245 with its internal UART
To: <hs@denx.de>, <linuxppc-embedded@ozlabs.org>
Message-ID: <005301c60078$b8dd1550$0760120a@photon>
Content-Type: text/plain; format=3Dflowed; charset=3D"iso-8859-1";
reply-type=3Doriginal
Hi,
I've tried this (CPC45_config) on Denx Kernel 2.4.25, and my serial =
console works now. Thank you very much.
Is there any similar platform for kernel 2.6 ? (i.e. MPC8245 with its =
internal UART )
thank you,
/HappyPhot
>=20
>> Who can tell me which flatform is similar to mine ? I've tried "make=20
>> sandpoint_defconfig", but seems not the right one.
>=20
> If you want to use Linux 2.4.25, you can try CPC45_defconfig from the=20
> Denx Kernel ...
------------------------------
Message: 4
Date: Wed, 14 Dec 2005 18:13:02 +1100
From: Dmytro Bablinyuk <dmytro.bablinyuk@rftechnology.com.au>
Subject: SPI driver for 82xx
To: linuxppc-embedded <Linuxppc-embedded@ozlabs.org>
Message-ID: <439FC5FE.8090703@rftechnology.com.au>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
Is anywhere available SPI driver (SPI peripheral) for 82xx for 2.6.x =
kernel?
I will appreciate any reference or suggestion.
Thank you
Dmytro
------------------------------
Message: 5
Date: Wed, 14 Dec 2005 11:21:02 +0100
From: Alex BASTOS <alebas@televes.com>
Subject: Re: pq2_find_bridges hangs system
To: Alex BASTOS <alebas@televes.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Message-ID: <1134555662.439ff20e6e812@webmail.televes.com:443>
Content-Type: text/plain; charset=3DISO-8859-15
Vitaly,
So, I have arrived to some conclusions.
1) With my previous kernel version (2.6.11) I had no problems because it =
had CONFIG_PCI_8260 and CONFIG_PPC_INDIRECT_PCI unset.
So I think no effective read/write operation was executed, and so that, =
no Machine Check.
In fact, this is the configuration I would prefer for my board. I have =
to set CONFIG_PCI for enabling USB, but I don't want all the HW stuff of =
the PCI. I can get these also with 2.6.15 if I modify Kconfig, to allow =
me to unset PCI_8260 (and then PPC_INDIRECT_PCI) for my board.
With that, the problem dissapears and I can boot 2.6.15.
Shouldn't this (PCI_8260) be visible from xconfig for those like me who =
wants USB (=3D> CONFIG_PCI) but don't really have any PCI device?
2) Although I am using Uboot 1.1.4, it is not top of git. I have found =
your changes to support PCI on 8272ADS for u-boot are not still applied =
on the version i am using. So, could this be causing the problem? Is =
there any configuration done in u-boot required by the PCI on the linux =
kernel to boot (BR3,OR3, EMR, ...)?
I should say that, on ADS, I have an older version of u-boot, 1.1.2, and =
it boots OK.
3) I have seen that from u-boot, a reset occurs when I read Internal =
Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same =
all PCI section on IM becomes zero. Is this a known behaviour? May this =
reflect a hardware problem?
In conclusion, 1) solves my "must", a working board (without PCI).
But I still would like to know what am I doing so wrong with this.
Best regards,
Alex
Citando Alex BASTOS <alebas@televes.com>:
> Vitaly,
>
> It didn't work. So I will check pq2ads_setup_pci to check if some=20
> board specific issue is affected.
>
> I will say you if I find anything
>
> Thanks
>
> Alex.
>
------------------------------
Message: 6
Date: Wed, 14 Dec 2005 14:29:34 +0300
From: Vitaly Bordug <vbordug@ru.mvista.com>
Subject: Re: pq2_find_bridges hangs system
To: Alex BASTOS <alebas@televes.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Message-ID: <43A0021E.7030406@ru.mvista.com>
Content-Type: text/plain; charset=3DISO-8859-15; format=3Dflowed
Alex BASTOS wrote:
> Vitaly,
>=20
> So, I have arrived to some conclusions.
>=20
> 1) With my previous kernel version (2.6.11) I had no problems because=20
> it had CONFIG_PCI_8260 and CONFIG_PPC_INDIRECT_PCI unset.
> So I think no effective read/write operation was executed, and so=20
> that, no Machine Check.
>=20
> In fact, this is the configuration I would prefer for my board. I have =
> to set CONFIG_PCI for enabling USB, but I don't want all the HW stuff=20
> of the PCI. I can get these also with 2.6.15 if I modify Kconfig, to=20
> allow me to unset PCI_8260 (and then PPC_INDIRECT_PCI) for my board.
> With that, the problem dissapears and I can boot 2.6.15.
>=20
> Shouldn't this (PCI_8260) be visible from xconfig for those like me=20
> who wants USB (=3D> CONFIG_PCI) but don't really have any PCI device?
>=20
Maybe, but I guess more correct is to deal with USB->PCI dependency..=20
Is it really needed(I am not USB expert)?
> 2) Although I am using Uboot 1.1.4, it is not top of git. I have found =
> your changes to support PCI on 8272ADS for u-boot are not still=20
> applied on the version i am using. So, could this be causing the=20
> problem? Is there any configuration done in u-boot required by the PCI =
> on the linux kernel to boot (BR3,OR3, EMR, ...)?
>=20
> I should say that, on ADS, I have an older version of u-boot, 1.1.2,=20
> and it boots OK.
>=20
My changes do not required for kernel to deal with PCI, that patch just =
allows access to PCI in U-Boot. Hence I might be useful if you'll head =
for resolving this issue which I guess unlikely to happen
> 3) I have seen that from u-boot, a reset occurs when I read Internal=20
> Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same=20
> all PCI section on IM becomes zero. Is this a known behaviour? May=20
> this reflect a hardware problem?
>=20
Sounds weird=20
> In conclusion, 1) solves my "must", a working board (without PCI).
> But I still would like to know what am I doing so wrong with this.
>=20
IMHO ability to disable PCI_8260 while PCI is on might be confusing, at =
least for upstream.
> Best regards,
>=20
> Alex
>=20
> Citando Alex BASTOS <alebas@televes.com>:
>=20
>> Vitaly,
>>
>> It didn't work. So I will check pq2ads_setup_pci to check if some=20
>> board specific issue is affected.
>>
>> I will say you if I find anything
>>
>> Thanks
>>
>> Alex.
>>
>=20
>=20
--
Sincerely,
Vitaly
------------------------------
Message: 7
Date: Wed, 14 Dec 2005 15:13:22 +0100
From: Alex BASTOS <alebas@televes.com>
Subject: [SOLVED] Re: pq2_find_bridges hangs system
To: Vitaly Bordug <vbordug@ru.mvista.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Message-ID: <1134569602.43a0288234662@webmail.televes.com:443>
Content-Type: text/plain; charset=3DISO-8859-15
Vitaly,
> Maybe, but I guess more correct is to deal with USB->PCI dependency..
> Is it really needed(I am not USB expert)?
Neither am I. I guess for this Host Controler it is not needed at HW =
level, but I am not sure why it is still required by the SW.
> > 3) I have seen that from u-boot, a reset occurs when I read Internal =
> > Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the=20
> > same all PCI section on IM becomes zero. Is this a known behaviour?
> > May this reflect a hardware problem?
> >
> Sounds weird
Here is the problem. The cause for this weird behaviour is that I had =
PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
I had disabled it trying to reduce power compsumption due to the PCI, as =
I am not going to use it. It seems it is not possible that way.
Any idea how to get this done?
> > In conclusion, 1) solves my "must", a working board (without PCI).
> > But I still would like to know what am I doing so wrong with this.
> >
> IMHO ability to disable PCI_8260 while PCI is on might be confusing,=20
> at least for upstream.
You are right.
Thanks so much for your help.
Best regards,
Alex
------------------------------
Message: 8
Date: Wed, 14 Dec 2005 17:14:51 +0300
From: Vitaly Bordug <vbordug@ru.mvista.com>
Subject: Re: [SOLVED] Re: pq2_find_bridges hangs system
To: Alex BASTOS <alebas@televes.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>
Message-ID: <43A028DB.5090906@ru.mvista.com>
Content-Type: text/plain; charset=3DISO-8859-15; format=3Dflowed
Alex BASTOS wrote:
> Vitaly,
>=20
>> Maybe, but I guess more correct is to deal with USB->PCI dependency..
>> Is it really needed(I am not USB expert)?
>=20
> Neither am I. I guess for this Host Controler it is not needed at HW=20
> level, but I am not sure why it is still required by the SW.
>=20
>=20
>>> 3) I have seen that from u-boot, a reset occurs when I read Internal =
>>> Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the=20
>>> same all PCI section on IM becomes zero. Is this a known behaviour?
>>> May this reflect a hardware problem?
>>>
>> Sounds weird
>=20
> Here is the problem. The cause for this weird behaviour is that I had=20
> PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
> I had disabled it trying to reduce power compsumption due to the PCI,=20
> as I am not going to use it. It seems it is not possible that way.
> Any idea how to get this done?
>=20
Well, I guess the best you can do now - just use custom tree. I'll try =
to find good solution for such a case (PCI required by deps but not hw) =
next time I'll touch PCI.
>>> In conclusion, 1) solves my "must", a working board (without PCI).
>>> But I still would like to know what am I doing so wrong with this.
>>>
>> IMHO ability to disable PCI_8260 while PCI is on might be confusing,=20
>> at least for upstream.
>=20
> You are right.
>=20
> Thanks so much for your help.
>=20
> Best regards,
>=20
> Alex
>=20
>=20
--
Sincerely,
Vitaly
------------------------------
Message: 9
Date: Wed, 14 Dec 2005 19:58:40 +0530
From: Robin Mathew <robbinmathew@gmail.com>
Subject: 8260 ethernet driver multicast problem
To: linuxppc-embedded@ozlabs.org
Message-ID:
<5b74ec4d0512140628y42986bc0h2f107e788dd115b6@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"
Hi,
I was encountering a problem with the receipt of multicast packets from =
eth interface in 8260 platform. The issue was traced to the fcc_enet.c =
driver. A stray return in the set_multicast_list function was the =
culprit.
The following is the changes that I have made-
Index: fcc_enet.c
@@ -1488,7 +1488,6 @@
cep =3D (struct fcc_enet_private *)dev->priv;
-return;
/* Get pointer to FCC area in parameter RAM.
*/
ep =3D (fcc_enet_t *)dev->base_addr;
Can you please tell me whether there is any issue with setting the =
driver in multicast or promiscous mode. Was this change deliberately =
done or is it really a bug?
Thanks in advance,
Robin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: =
http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20051214/af24a6=
1a/attachment.html
------------------------------
Message: 10
Date: Wed, 14 Dec 2005 08:30:48 -0600
From: Kumar Gala <galak@kernel.crashing.org>
Subject: Re: [SOLVED] Re: pq2_find_bridges hangs system
To: Vitaly Bordug <vbordug@ru.mvista.com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs.org>, Alex BASTOS
<alebas@televes.com>
Message-ID: <386A8114-FA1C-44E2-A8F1-CF48F4AF495E@kernel.crashing.org>
Content-Type: text/plain; charset=3DUS-ASCII; delsp=3Dyes; =
format=3Dflowed
On Dec 14, 2005, at 8:14 AM, Vitaly Bordug wrote:
> Alex BASTOS wrote:
>> Vitaly,
>>> Maybe, but I guess more correct is to deal with USB->PCI=20
>>> dependency..
>>> Is it really needed(I am not USB expert)?
>> Neither am I. I guess for this Host Controler it is not needed at HW=20
>> level, but I am not sure why it is still required by the SW.
>>>> 3) I have seen that from u-boot, a reset occurs when I read=20
>>>> Internal Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I=20
>>>> do the same all PCI section on IM becomes zero. Is this a known=20
>>>> behaviour?
>>>> May this
>>>> reflect a hardware problem?
>>>>
>>> Sounds weird
>> Here is the problem. The cause for this weird behaviour is that I had =
>> PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
>> I had disabled it trying to reduce power compsumption due to the PCI, =
>> as I am not going to use it. It seems it is not possible that way.
>> Any idea how to get this done?
I'm guessing you dont have anything else doing arbitration on the bus.
- kumar
------------------------------
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
End of Linuxppc-embedded Digest, Vol 16, Issue 36
*************************************************
^ permalink raw reply
* Re: [PATCH] via-mpu: compile without Power Management support
From: Paul Mackerras @ 2005-12-15 5:30 UTC (permalink / raw)
To: Kristian Mueller; +Cc: linuxppc-dev
In-Reply-To: <1134621116.4972.19.camel@pismo>
Kristian Mueller writes:
> Fix compilation of via-mpu.c without Power Management support.
I'll take this without a Signed-off-by line this time, since it's
pretty trivial, but in general please include a Signed-off-by line
(see Documentation/SubmittingPatches for what that is).
Paul.
^ permalink raw reply
* Re: 8260 ethernet driver multicast problem
From: Robin Mathew @ 2005-12-15 5:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]
Hi,
I am using 2.4.20 kernel. I have checked up the latest sources in denx.
Think the problem is fixed with the latest sources.
Thanks
Robin
On 12/15/05, linuxppc-embedded-request@ozlabs.org <
linuxppc-embedded-request@ozlabs.org> wrote:
>
>
> 1. Re: 8260 ethernet driver multicast problem (Pantelis Antoniou)
> 2. Re: 8260 ethernet driver multicast problem (Andy Fleming)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 14 Dec 2005 17:20:01 +0200
> From: Pantelis Antoniou <panto@intracom.gr>
> Subject: Re: 8260 ethernet driver multicast problem
> To: Robin Mathew <robbinmathew@gmail.com>
> Cc: linuxppc-embedded@ozlabs.org
> Message-ID: <43A03821.6040206@intracom.gr>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Robin Mathew wrote:
> > Hi,
> > I was encountering a problem with the receipt of multicast packets from
> eth
> > interface in 8260 platform. The issue was traced to the fcc_enet.c
> driver. A
> > stray return in the set_multicast_list function was the culprit.
> >
> > The following is the changes that I have made-
> >
> > Index: fcc_enet.c
> > @@ -1488,7 +1488,6 @@
> >
> > cep = (struct fcc_enet_private *)dev->priv;
> >
> > -return;
> > /* Get pointer to FCC area in parameter RAM.
> > */
> > ep = (fcc_enet_t *)dev->base_addr;
> >
> >
> > Can you please tell me whether there is any issue with setting the
> driver in
> > multicast or promiscous mode. Was this change deliberately done or is it
> > really a bug?
> >
> > Thanks in advance,
> > Robin
> >
>
> Robin, what's the kernel version you're using?
>
> If you're using 2.6 there's a brand new driver you can use.
>
> Regards
>
> Pantelis
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 14 Dec 2005 14:13:00 -0600
> From: Andy Fleming <afleming@freescale.com>
> Subject: Re: 8260 ethernet driver multicast problem
> To: Pantelis Antoniou <panto@intracom.gr>
> Cc: Robin Mathew <robbinmathew@gmail.com>,
> linuxppc-embedded@ozlabs.org
> Message-ID: <2750D02C-4FDE-4267-8B60-E1CECDFF55F4@freescale.com>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>
>
> On Dec 14, 2005, at 09:20, Pantelis Antoniou wrote:
>
> > Robin Mathew wrote:
> >> Hi,
> >> I was encountering a problem with the receipt of multicast packets
> >> from eth
> >> interface in 8260 platform. The issue was traced to the fcc_enet.c
> >> driver. A
> >> stray return in the set_multicast_list function was the culprit.
> >> The following is the changes that I have made-
> >> Index: fcc_enet.c
> >> @@ -1488,7 +1488,6 @@
> >> cep = (struct fcc_enet_private *)dev->priv;
> >> -return;
> >> /* Get pointer to FCC area in parameter RAM.
> >> */
> >> ep = (fcc_enet_t *)dev->base_addr;
> >> Can you please tell me whether there is any issue with setting the
> >> driver in
> >> multicast or promiscous mode. Was this change deliberately done or
> >> is it
> >> really a bug?
> >> Thanks in advance,
> >> Robin
> >
> > Robin, what's the kernel version you're using?
> >
> > If you're using 2.6 there's a brand new driver you can use.
>
>
> Has 8260 platform support been pushed out yet?
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> End of Linuxppc-embedded Digest, Vol 16, Issue 37
> *************************************************
>
[-- Attachment #2: Type: text/html, Size: 5190 bytes --]
^ permalink raw reply
* Re: Linux dependency for PCI Window on U-Boot
From: Kumar Gala @ 2005-12-15 6:22 UTC (permalink / raw)
To: KS Soumya-ask067; +Cc: linuxppc-embedded
In-Reply-To: <C82A9B11BE247C4E952DC733EA98DAA1C55006@ZMY16EXM66.ds.mot.com>
>
>
> Hi,
> Is there anything more specific that I need to do to enable my PCI
> window to 512MB? I'm using Linux kernel 2.4.20 / KO2.6.10 with
> MPC8540 ADS defconfig and U-Boot for the same. By default, the U-
> Boot is specifying a window of 256MB (0x80000000 - 0x8fffffff).
> Even if the Linux specifies 512MB (0x80000000 - 0x9fffffff), I am
> not able to access my device registers on 9f4f0000 (BAR of my device).
> But if I specify in U-Boot to make the PCI window as 512MB, (or if
> I make the Linux to hold 256MB) then Im able to access my device.
> What should I do for my kernel not to be dependent on U-Boot for
> the same?
> Any pointers would be of great help. Thank you.
This is most likely due to setting up of the ECM Local access window
registers. We dont do this in the kernel and expect that the boot
loader has setup the physical address map. If you dont want to be
dependent on u-boot you should add code to your kernel for setting up
the LAWs to the kernel for PCI.
- kumar
^ permalink raw reply
* Help: mcc driver for mpc8260
From: s.maiti @ 2005-12-15 6:49 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: John.Round
In-Reply-To: <20051215010005.39B2A6888B@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
Dear all,
I have downloaded the souce code of mcc for 8260 from sourceforge website.
I will be highly grateful to you people if you can clear my confusion
regarding the mcc driver for mpc8260:
1) What I have to do if I want to use all 128 channels to route through
TDM B of mcc1?
2) What will be the SI RAM & SI Mode Registers contents?
3) What will be the content of MCCF1?
Thanks in advance........
Souvik Maiti
Tata Consultancy Services Limited
Bengal Intelligent Park
Bldg. - D, Plots - A2, M2 & N2
Block - GP, Sector V
Salt Lake Electronics Complex
Kolkata - 700091, West Bengal
India
Mailto: s.maiti@tcs.com
Website: http://www.tcs.com
Notice: The 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
[-- Attachment #2: Type: text/html, Size: 1649 bytes --]
^ permalink raw reply
* Re: [SOLVED] Re: pq2_find_bridges hangs system
From: Alex BASTOS @ 2005-12-15 9:39 UTC (permalink / raw)
To: linuxppc-embedded list
In-Reply-To: <386A8114-FA1C-44E2-A8F1-CF48F4AF495E@kernel.crashing.org>
Kumar,
> >> Here is the problem. The cause for this weird behaviour is that I
> >> had PCI_ARBITER_EN_ disabled. So, a HW problem at the end.
> >> I had disabled it trying to reduce power compsumption due to the PCI,
> >> as I am not going to use it. It seems it is not possible that way.
> >> Any idea how to get this done?
>
> I'm guessing you dont have anything else doing arbitration on the bus.
You're right. I wasn't using the PCI at all.
>
> - kumar
>
Best regards,
Alex
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Michael Hanselmann @ 2005-12-15 8:37 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: kernel-stuff, linux-kernel, linuxppc-dev, linux-input
In-Reply-To: <200512142243.28390.dtor_core@ameritech.net>
On Wed, Dec 14, 2005 at 10:43:27PM -0500, Dmitry Torokhov wrote:
> The adjusted patch is below. I am still not sure if this really should be
> in mainline. Was it ever used?
That patch looks fine for me.
I would like to see it in mainline because it makes debugging and
figuring out new protocols much easier. For example, Apple changed the
protocol with the latest PowerBooks (see the other patch for that). Why
should everyone willing to implement a new protocol rewrite this code?
^ permalink raw reply
* help reqd for mpc8260 linux
From: prabha.j @ 2005-12-15 9:22 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]
Hi All,
I working on custom board(mpc8260) . Now the bootlader is working and when
i dowload the kernel image through u-boot it gives messages as
"Transferring Conrol to Linux" and then nothing comes. I am using
Linux-2.4.25 and eldk toolkit ,both from denx.
My boards memory map is SDRAM starts from 0 and flash starts from
0x30000000. and baudrate is 57600
When i was debugging in
start_here(arch/ppc/kernel/head.S)
It is passing the machine_init and MMU_init(This i have seen by putting
printk and seeing it in log_buf) and then in this code
lis r4,2f@h
ori r4,r4,2f@l
tophys(r4,r4)
li r3,MSR_KERNEL & ~(MSR_IR|MSR_DR)
FIX_SRR1(r3,r5)
mtspr SRR0,r4
mtspr SRR1,r3
SYNC
bl MMU_init_prabha //(This is just a printk function).Till
here its working.
RFI
If i put the printk after this funtion i am not getting anything in the
log_buf. I simply commented the RFI instruction then also i didn't see any
messages.
Can anybody tell me what may be the problem.
Waiting for reply.
Thanks in advance.
Best Regards
Prabha J.
Tata Consultancy Services Limited
Mailto: prabha.j@tcs.com
Website: http://www.tcs.com
Notice: The 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
[-- Attachment #2: Type: text/html, Size: 3066 bytes --]
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Johannes Berg @ 2005-12-15 9:40 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev
In-Reply-To: <9892D605-1B30-4094-AEEC-9DA6F3B13B05@freescale.com>
Andy Fleming wrote:
> What platform is this on? The copy from user stuff is a bit out of
> my area of expertise, but I've got an implementation of backtrace for
> oprofile running on 85xx. Mostly, it's just a hacked up version of
> the ppc64 patch that was floating around.
ppc32, compiling the kernel with ARCH=ppc still.
johannes
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Johannes Berg @ 2005-12-15 9:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17312.38814.551675.906916@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
>> So I run across this warning:
>> [ 2724.595549] Debug: sleeping function called from invalid context at
>> arch/ppc/kernel/traps.c:528
>> [ 2724.595563] in_atomic():0, irqs_disabled():1
>
> Hmmm. What kernel version is this? I assume you are using ARCH=ppc,
> is that right?
2.6.15-rc5, IIRC (might have been rc1, I currently need to use both
kernels depending on what I want to do), and yes, ARCH=ppc.
> No, it doesn't mean that. However, if the page isn't in memory,
> __copy_from_user_inatomic won't try to bring it in if it has been
> called from an atomic context (i.e. preempt or interrupts disabled).
Good, thanks. So essentially __copy_from_user has the same logic (since it
just calls __copy_from_user_inatomic) but calls might_sleep() to show the
developer what he's doing wrong although it won't actually hurt. Right?
> The real question is why we have interrupts disabled in the illegal
> instruction handler. There was a reason why I wanted interrupts
> disabled on entry to program_check_exception which I don't recall
> clearly at the moment, but I think program_check_exception should be
> doing a local_irq_enable() at some point (and it also shouldn't be
> trying to emulate instructions for the kernel).
I don't have the code here right now but I did have a userspace program
that it tried to emulate (so I'm not sure if it would try to emulate
kernel instructions). And it wouldn't emulate that instruction, my program
died with SIGILL, but obviously it still needs to load it to see what kind
of instruction it was.
johannes
^ permalink raw reply
* Re: 8260 ethernet driver multicast problem
From: Vitaly Bordug @ 2005-12-15 9:59 UTC (permalink / raw)
To: Andy Fleming; +Cc: Robin Mathew, linuxppc-embedded
In-Reply-To: <2750D02C-4FDE-4267-8B60-E1CECDFF55F4@freescale.com>
Andy Fleming wrote:
>
> On Dec 14, 2005, at 09:20, Pantelis Antoniou wrote:
>
>> Robin Mathew wrote:
>>> Hi,
>>> I was encountering a problem with the receipt of multicast packets
>>> from eth
>>> interface in 8260 platform. The issue was traced to the fcc_enet.c
>>> driver. A
>>> stray return in the set_multicast_list function was the culprit.
>>> The following is the changes that I have made-
>>> Index: fcc_enet.c
>>> @@ -1488,7 +1488,6 @@
>>> cep = (struct fcc_enet_private *)dev->priv;
>>> -return;
>>> /* Get pointer to FCC area in parameter RAM.
>>> */
>>> ep = (fcc_enet_t *)dev->base_addr;
>>> Can you please tell me whether there is any issue with setting the
>>> driver in
>>> multicast or promiscous mode. Was this change deliberately done or is it
>>> really a bug?
>>> Thanks in advance,
>>> Robin
>>
>> Robin, what's the kernel version you're using?
>>
>> If you're using 2.6 there's a brand new driver you can use.
>
>
> Has 8260 platform support been pushed out yet?
>
Guess it's not in the stock so far (And I have to update ppc_sys to make the things right), but patches are available here in the list archives.
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* USB webcam driver
From: Leena Vachhani @ 2005-12-15 10:14 UTC (permalink / raw)
To: linuxppc-embedded
I am trying to compile USB webcam driver (which works fine with RH 9.0 linux
2.4.20-8 kernel) with montavista linux for IBM PPC405 architecture. The header
file asm/current.h is giving error as "Invalid register name for 'current'".
Header file current.h has only one statement :
register struct task_struct *current asm ("r2");
I don't have any clue what is the problem in this statement. Please help me out.
Thanks
Leena Vachhani
^ permalink raw reply
* help needed:Which file is the key file in the ELF(for linux) linker?
From: zengshuai @ 2005-12-15 12:38 UTC (permalink / raw)
To: ppc
//hello.c
int main()
{
int a;
a=1;
}
--------------------------
first time:
#gcc -c -o hello.o hello.c
#ld -o hello.elf hello.o
#file hello.elf
hello.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
statically inked, not stripped
second time:
#gcc -c -o hello.o hello.c
#ld -static hello.o /usr/lib/crt1.o /usr/lib/crti.o /usr/
ib/crtn.o /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/crtbegin.o /usr/lib/gcc-lib/
386-redhat-linux/3.2.2/crtend.o -L/usr/lib -lc /usr/lib/gcc-lib/i386-redhat-lin
x/3.2.2/libgcc.a -o hello.elf
#file hello.elf
hello.elf: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
for GNU/Linx 2.2.5, statically linked, not stripped
~~~~~~~~~~~~~~~~~~
So,which file is the key file,which cause the change,from elf to linux elf?
How to compile a ELF file using in bareboard and how to compile a ELF file
using in Linux really puzzles me a lot.thanks
------------------------------
我现在使用Sogou.com的2G邮箱了，你也来试试吧!
http://mail.sogou.com/recommend/sogoumail_invite_reg1.jsp?from=sogouinvitation&s_EMAIL=zengshuai%40sogou.com&username=linuxppc-embedded&FullName=linuxppc-embedded&Email=linuxppc-embedded%40ozlabs.org&verify=755eff4e640bdcfc57d93cbd8b0a9cb7
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Kumar Gala @ 2005-12-15 14:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <4590.131.234.232.31.1134639886.squirrel@secure.sipsolutions.net>
On Dec 15, 2005, at 3:44 AM, Johannes Berg wrote:
> Paul Mackerras wrote:
>>> So I run across this warning:
>>> [ 2724.595549] Debug: sleeping function called from invalid
>>> context at
>>> arch/ppc/kernel/traps.c:528
>>> [ 2724.595563] in_atomic():0, irqs_disabled():1
>>
>> Hmmm. What kernel version is this? I assume you are using ARCH=ppc,
>> is that right?
>
> 2.6.15-rc5, IIRC (might have been rc1, I currently need to use both
> kernels depending on what I want to do), and yes, ARCH=ppc.
>
>> No, it doesn't mean that. However, if the page isn't in memory,
>> __copy_from_user_inatomic won't try to bring it in if it has been
>> called from an atomic context (i.e. preempt or interrupts disabled).
>
> Good, thanks. So essentially __copy_from_user has the same logic
> (since it
> just calls __copy_from_user_inatomic) but calls might_sleep() to
> show the
> developer what he's doing wrong although it won't actually hurt.
> Right?
>
>> The real question is why we have interrupts disabled in the illegal
>> instruction handler. There was a reason why I wanted interrupts
>> disabled on entry to program_check_exception which I don't recall
>> clearly at the moment, but I think program_check_exception should be
>> doing a local_irq_enable() at some point (and it also shouldn't be
>> trying to emulate instructions for the kernel).
>
> I don't have the code here right now but I did have a userspace
> program
> that it tried to emulate (so I'm not sure if it would try to emulate
> kernel instructions). And it wouldn't emulate that instruction, my
> program
> died with SIGILL, but obviously it still needs to load it to see
> what kind
> of instruction it was.
Out of interest, is there a reason you dont handle the emulation in
user space?
- kumar
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Johannes Berg @ 2005-12-15 14:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <44B795CA-E338-4AAC-937D-F2EEA5E27EB9@kernel.crashing.org>
On Do, 2005-12-15 at 08:04 -0600, Kumar Gala wrote:
> Out of interest, is there a reason you dont handle the emulation in
> user space?
I'm not even interested in emulating that at all, the kernel just
checked if it could emulate it (couldn't, so my program died with
SIGILL)...
To tell the truth, I was just testing what would happen and wrote a
buggy program.
johannes
^ permalink raw reply
* Re: illegal instructions / irqs disabled warning
From: Kumar Gala @ 2005-12-15 15:47 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev
In-Reply-To: <1134655801.5787.1.camel@localhost>
On Dec 15, 2005, at 8:10 AM, Johannes Berg wrote:
> On Do, 2005-12-15 at 08:04 -0600, Kumar Gala wrote:
>
>> Out of interest, is there a reason you dont handle the emulation in
>> user space?
>
> I'm not even interested in emulating that at all, the kernel just
> checked if it could emulate it (couldn't, so my program died with
> SIGILL)...
> To tell the truth, I was just testing what would happen and wrote a
> buggy program.
Ahh, you should check out LTP its got some tests like this which
generate random instruction images and see what happens. Helps
finding kernel bugs.
- kumar
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Olof Johansson @ 2005-12-15 19:50 UTC (permalink / raw)
To: Michael Hanselmann
Cc: linux-input, linuxppc-dev, dtor_core, linux-kernel, kernel-stuff
In-Reply-To: <20051214233108.GA20127@hansmi.ch>
On Thu, Dec 15, 2005 at 12:31:08AM +0100, Michael Hanselmann wrote:
> This patch adds support for relayfs to the appletouch driver to make debugging
> easier.
I think I agree with previous comments regarding debug code in the driver:
It's unlikely to ever be used by more than a couple of people at very
rare occasions (new hardware releases), and the barrier to using it is
still high; new users need to learn how to parse the data anyway. I don't
see a reason to include this in mainline.
That aside, comments on the patch below.
> diff -rup linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c b/drivers/usb/input/appletouch.c
> --- linux-2.6.15-rc5.orig/drivers/usb/input/appletouch.c 2005-12-13 22:44:24.000000000 +0100
> +++ b/drivers/usb/input/appletouch.c 2005-12-15 00:25:09.000000000 +0100
> @@ -6,6 +6,8 @@
> * Copyright (C) 2005 Stelian Pop (stelian@popies.net)
> * Copyright (C) 2005 Frank Arnold (frank@scirocco-5v-turbo.de)
> * Copyright (C) 2005 Peter Osterlund (petero2@telia.com)
> + * Copyright (C) 2005 Parag Warudkar (parag.warudkar@gmail.com)
> + * Copyright (C) 2005 Michael Hanselmann (linux-kernel@hansmi.ch)
> *
> * Thanks to Alex Harper <basilisk@foobox.net> for his inputs.
> *
> @@ -35,6 +37,10 @@
> #include <linux/input.h>
> #include <linux/usb_input.h>
>
> +#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
> +#include <linux/relayfs_fs.h>
> +#endif
> +
> /* Apple has powerbooks which have the keyboard with different Product IDs */
> #define APPLE_VENDOR_ID 0x05AC
>
> @@ -73,6 +79,7 @@ MODULE_DEVICE_TABLE (usb, atp_table);
>
> /* maximum pressure this driver will report */
> #define ATP_PRESSURE 300
> +
Whitespace change
> /*
>
> * multiplication factor for the X and Y coordinates.
> * We try to keep the touchpad aspect ratio while still doing only simple
> @@ -124,7 +131,7 @@ struct atp {
> if (debug) printk(format, ##a); \
> } while (0)
>
> -MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold");
> +MODULE_AUTHOR("Johannes Berg, Stelian Pop, Frank Arnold, Parag Warudkar, Michael Hanselmann");
> MODULE_DESCRIPTION("Apple PowerBooks USB touchpad driver");
> MODULE_LICENSE("GPL");
>
> @@ -132,6 +139,68 @@ static int debug = 1;
> module_param(debug, int, 0644);
> MODULE_PARM_DESC(debug, "Activate debugging output");
>
> +#if defined(CONFIG_RELAYFS_FS) || defined(CONFIG_RELAYFS_FS_MODULE)
> +static int relayfs;
> +module_param(relayfs, int, 0444);
> +MODULE_PARM_DESC(relayfs, "Activate relayfs support");
> +
> +struct rchan *rch;
> +struct rchan_callbacks *rcb;
static, please.
> +
> +static inline void atp_relayfs_dump(struct atp *dev)
> +{
> + /* "rch" is NULL if relayfs is disabled */
> + if (rch && dev->data) {
> + relay_write(rch, dev->data, dev->urb->actual_length);
> + }
> +}
> +
> +static int appletouch_relayfs_init(void)
> +{
> + // Make sure the variables aren't initialized to some bogus value when
> + // relayfs is disabled
> + rcb = NULL;
> + rch = NULL;
Huh? BSS is initialized to 0, this is unneccessary.
(Also, the comment is C++-style, please use /* */ comments.)
> +
> + if (relayfs) {
Please do:
if (!relayfs)
return 0;
To save indentation.
> + rcb = kmalloc(sizeof(struct rchan_callbacks), GFP_KERNEL);
> + if (!rcb)
> + return -ENOMEM;
> +
> + rcb->subbuf_start = NULL;
> + rcb->buf_mapped = NULL;
> + rcb->buf_unmapped = NULL;
> +
> + rch = relay_open("atpdata", NULL, 256, 256, NULL);
> + if (!rch) {
> + kfree(rcb);
> + return -ENOMEM;
ENOMEM for a failed open? Seems odd to me.
Should you also set rcb = NULL?
> + }
> +
> + printk(KERN_INFO "appletouch: Relayfs enabled.\n");
> + }
> +
> + return 0;
> +}
> +
> +static void appletouch_relayfs_exit(void)
> +{
> + if (rch) {
> + printk(KERN_INFO "appletouch: Relayfs disabled\n");
> + relay_close(rch);
> + rch = NULL;
> + }
> + if (rcb) {
> + kfree(rcb);
> + rcb = NULL;
No need to check arguments to kfree.
> + }
> +}
> +#else
> +static inline void atp_relayfs_dump(struct atp *dev) { }
> +static int appletouch_relayfs_init(void) { return 0; }
> +static void appletouch_relayfs_exit(void) { }
> +#endif
> +
> static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact,
> int *z, int *fingers)
> {
> @@ -194,6 +263,8 @@ static void atp_complete(struct urb* urb
> goto exit;
> }
>
> + atp_relayfs_dump(dev);
> +
> /* reorder the sensors values */
> for (i = 0; i < 8; i++) {
> /* X values */
> @@ -297,6 +368,11 @@ exit:
> static int atp_open(struct input_dev *input)
> {
> struct atp *dev = input->private;
> + int result;
> +
> + result = appletouch_relayfs_init();
> + if (result < 0)
> + return result;
Sounds harsh to deny USB open just because relayfs couldn't be setup.
Actually, this way you could just make the init function not return
anything; it doesn't matter if it fails or not -- life will go on.
>
> if (usb_submit_urb(dev->urb, GFP_ATOMIC))
> return -EIO;
> @@ -310,6 +386,8 @@ static void atp_close(struct input_dev *
> struct atp *dev = input->private;
>
> usb_kill_urb(dev->urb);
> + appletouch_relayfs_exit();
> +
> dev->open = 0;
> }
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [RFC][PATCH] ppc32: Make platform devices being able to assign functions
From: Vitaly Bordug @ 2005-12-15 19:59 UTC (permalink / raw)
To: linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 560 bytes --]
The idea is to modify a .name field on a platform device, when PDs with the
same names are to be used within different drivers, as
<device_name> -> <device_name>:<function>
Corresponding drivers should change the .name in struct device_driver to
reflect upper of course.
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
This is preliminary version, maybe some issues still need not be cleaned up, and there is no
"generic" platform_notify for board_specific code yet, but I'd like to see opinions concerning this stuff meantime.
--
Sincerely,
Vitaly
[-- Attachment #2: ppc_sys_addon2.patch --]
[-- Type: text/x-patch, Size: 6785 bytes --]
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
index c0b93c4..568b40b 100644
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -15,11 +15,24 @@
*/
#include <linux/string.h>
+#include <linux/bootmem.h>
+#include <linux/platform_device.h>
#include <asm/ppc_sys.h>
int (*ppc_sys_device_fixup) (struct platform_device * pdev);
static int ppc_sys_inited;
+static int ppc_sys_func_inited;
+
+static const char *ppc_sys_func_names[] = {
+ [FUNC_ENABLED] = "dummy",
+ [FUNC_ETH] = "eth",
+ [FUNC_UART] = "uart",
+ [FUNC_HLDC] = "hldc",
+ [FUNC_USB] = "usb",
+ [FUNC_IRDA] = "irda",
+ [FUNC_DISABLED] = "off",
+};
void __init identify_ppc_sys_by_id(u32 id)
{
@@ -38,13 +51,13 @@ void __init identify_ppc_sys_by_id(u32 i
void __init identify_ppc_sys_by_name(char *name)
{
unsigned int i = 0;
- while (ppc_sys_specs[i].ppc_sys_name[0])
- {
+ while (ppc_sys_specs[i].ppc_sys_name[0]) {
if (!strcmp(ppc_sys_specs[i].ppc_sys_name, name))
break;
i++;
}
cur_ppc_sys_spec = &ppc_sys_specs[i];
+
return;
}
@@ -128,6 +141,92 @@ void ppc_sys_device_remove(enum ppc_sys_
}
}
+/*
+ Function assignment stuff.
+ Intended to work as follows:
+ the device name defined in foo_devices.c will be concatenated with :"func",
+ where func is string map of respective function from platfom_device_func enum
+
+ The FUNC_ENABLED function is intended to remove all assignments, making the device to appear
+ in platform bus with unmodified name.
+ */
+
+/*
+ Here we'll replace .name pointers with fixed-lenght strings
+ Hereby, this should be called *before* any func stuff triggeded.
+ */
+void ppc_sys_device_initfunc(void)
+{
+ int i;
+ const char *name;
+ static char new_names[NUM_PPC_SYS_DEVS][BUS_ID_SIZE];
+ enum ppc_sys_devices cur_dev;
+
+ /* If inited yet, do nothing */
+ if (ppc_sys_func_inited)
+ return;
+
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
+ if ((cur_dev = cur_ppc_sys_spec->device_list[i]) < 0)
+ continue;
+
+ if (ppc_sys_platform_devices[cur_dev].name) {
+ /*backup name */
+ name = ppc_sys_platform_devices[cur_dev].name;
+ strlcpy(new_names[i], name, BUS_ID_SIZE);
+ ppc_sys_platform_devices[cur_dev].name = new_names[i];
+ }
+ }
+
+ ppc_sys_func_inited =1;
+}
+
+/*The "engine" of the func stuff. Here we either concat specified function string description
+ to the name, or remove it if FUNC_ENABLED parameter is passed here*/
+void ppc_sys_device_setfunc(enum ppc_sys_devices dev,
+ enum platform_device_func func)
+{
+ char *s;
+ char *name = (char *)ppc_sys_platform_devices[dev].name;
+ char tmp[BUS_ID_SIZE];
+
+ if(!ppc_sys_func_inited) {
+ printk (KERN_ERR"Unable to later function - not inited!\n");
+ return;
+ }
+
+ if (ppc_sys_inited) {
+ platform_device_unregister(&ppc_sys_platform_devices[dev]);
+ }
+
+ if ((s = (char *)strchr(name, ':')) != NULL) { /* reassign */
+ /* Either change the name after ':' or remove func modifications */
+ if (func != FUNC_ENABLED)
+ strlcpy(s + 1, ppc_sys_func_names[func], BUS_ID_SIZE);
+ else
+ *s = 0;
+ } else if (func != FUNC_ENABLED) {
+ /* do assignment if it is not just "enable" request */
+ sprintf(tmp, "%s:%s", name, ppc_sys_func_names[func]);
+ strlcpy(name, tmp, BUS_ID_SIZE);
+ }
+
+ if (ppc_sys_inited) {
+ platform_device_register(&ppc_sys_platform_devices[dev]);
+ }
+}
+
+void ppc_sys_device_set_func_all(enum platform_device_func func)
+{
+ enum ppc_sys_devices cur_dev;
+ int i;
+
+ for (i = 0; i < cur_ppc_sys_spec->num_devices; i++) {
+ cur_dev = cur_ppc_sys_spec->device_list[i];
+ ppc_sys_device_setfunc(cur_dev, func);
+ }
+}
+
static int __init ppc_sys_init(void)
{
unsigned int i, dev_id, ret = 0;
diff --git a/include/asm-ppc/mpc10x.h b/include/asm-ppc/mpc10x.h
index 77b1e09..976ad3d 100644
--- a/include/asm-ppc/mpc10x.h
+++ b/include/asm-ppc/mpc10x.h
@@ -165,6 +165,7 @@ enum ppc_sys_devices {
MPC10X_DMA1,
MPC10X_UART0,
MPC10X_UART1,
+ NUM_PPC_SYS_DEVS,
};
int mpc10x_bridge_init(struct pci_controller *hose,
diff --git a/include/asm-ppc/mpc52xx.h b/include/asm-ppc/mpc52xx.h
index e5f80c2..b2cb44f 100644
--- a/include/asm-ppc/mpc52xx.h
+++ b/include/asm-ppc/mpc52xx.h
@@ -49,6 +49,7 @@ enum ppc_sys_devices {
MPC52xx_ATA,
MPC52xx_I2C1,
MPC52xx_I2C2,
+ NUM_PPC_SYS_DEVS,
};
diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
index 3214526..6ba69a8 100644
--- a/include/asm-ppc/mpc8260.h
+++ b/include/asm-ppc/mpc8260.h
@@ -83,6 +83,7 @@ enum ppc_sys_devices {
MPC82xx_CPM_SMC2,
MPC82xx_CPM_USB,
MPC82xx_SEC1,
+ NUM_PPC_SYS_DEVS,
};
#ifndef __ASSEMBLY__
diff --git a/include/asm-ppc/mpc83xx.h b/include/asm-ppc/mpc83xx.h
index 7cdf60f..3c23fc4 100644
--- a/include/asm-ppc/mpc83xx.h
+++ b/include/asm-ppc/mpc83xx.h
@@ -108,6 +108,7 @@ enum ppc_sys_devices {
MPC83xx_USB2_DR,
MPC83xx_USB2_MPH,
MPC83xx_MDIO,
+ NUM_PPC_SYS_DEVS,
};
#endif /* CONFIG_83xx */
diff --git a/include/asm-ppc/mpc85xx.h b/include/asm-ppc/mpc85xx.h
index 9d14bae..2a77884 100644
--- a/include/asm-ppc/mpc85xx.h
+++ b/include/asm-ppc/mpc85xx.h
@@ -135,6 +135,7 @@ enum ppc_sys_devices {
MPC85xx_eTSEC4,
MPC85xx_IIC2,
MPC85xx_MDIO,
+ NUM_PPC_SYS_DEVS,
};
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
index 46f159c..90e3d59 100644
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -111,6 +111,7 @@ enum ppc_sys_devices {
MPC8xx_CPM_SMC1,
MPC8xx_CPM_SMC2,
MPC8xx_CPM_USB,
+ NUM_PPC_SYS_DEVS,
};
#ifndef BOARD_CHIP_NAME
diff --git a/include/asm-ppc/ppc_sys.h b/include/asm-ppc/ppc_sys.h
index 83d8c77..02f812f 100644
--- a/include/asm-ppc/ppc_sys.h
+++ b/include/asm-ppc/ppc_sys.h
@@ -72,5 +72,11 @@ extern void *ppc_sys_get_pdata(enum ppc_
/* remove a device from the system */
extern void ppc_sys_device_remove(enum ppc_sys_devices dev);
+/*Function assignment stuff*/
+void ppc_sys_device_initfunc(void);
+void ppc_sys_device_setfunc(enum ppc_sys_devices dev,
+ enum platform_device_func func);
+void ppc_sys_device_set_func_all(enum platform_device_func func);
+
#endif /* __ASM_PPC_SYS_H */
#endif /* __KERNEL__ */
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 17e336f..346796f 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -21,6 +21,16 @@ struct platform_device {
struct resource * resource;
};
+enum platform_device_func {
+ FUNC_ENABLED = 0,
+ FUNC_ETH = 1,
+ FUNC_UART = 2,
+ FUNC_HLDC = 3,
+ FUNC_USB = 4,
+ FUNC_IRDA = 5,
+ FUNC_DISABLED = 6,
+};
+
#define to_platform_device(x) container_of((x), struct platform_device, dev)
extern int platform_device_register(struct platform_device *);
^ permalink raw reply related
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Michael Hanselmann @ 2005-12-15 21:26 UTC (permalink / raw)
To: Olof Johansson
Cc: linux-input, linuxppc-dev, dtor_core, linux-kernel, kernel-stuff
In-Reply-To: <20051215195017.GA7195@pb15.lixom.net>
On Thu, Dec 15, 2005 at 11:50:17AM -0800, Olof Johansson wrote:
> I think I agree with previous comments regarding debug code in the driver:
> It's unlikely to ever be used by more than a couple of people at very
> rare occasions (new hardware releases), and the barrier to using it is
> still high; new users need to learn how to parse the data anyway. I don't
> see a reason to include this in mainline.
Okay, based on your comments, please drop that patch. How about the one
to support the Geyser 2 device? Should I do a rediff without relayfs
support?
Greets,
Michael
^ permalink raw reply
* Re: [PATCH 2.6 1/2] usb/input: Add relayfs support to appletouch driver
From: Dmitry Torokhov @ 2005-12-15 21:38 UTC (permalink / raw)
To: Michael Hanselmann; +Cc: linuxppc-dev, linux-kernel, linux-input, kernel-stuff
In-Reply-To: <20051215212635.GA6195@hansmi.ch>
On 12/15/05, Michael Hanselmann <linux-kernel@hansmi.ch> wrote:
> On Thu, Dec 15, 2005 at 11:50:17AM -0800, Olof Johansson wrote:
> > I think I agree with previous comments regarding debug code in the driv=
er:
> > It's unlikely to ever be used by more than a couple of people at very
> > rare occasions (new hardware releases), and the barrier to using it is
> > still high; new users need to learn how to parse the data anyway. I don=
't
> > see a reason to include this in mainline.
>
> Okay, based on your comments, please drop that patch. How about the one
> to support the Geyser 2 device? Should I do a rediff without relayfs
> support?
>
If you could rediff it without relayfs I would add it to the input
tree. Altough I am not sure if manually unrolling that loop is such a
good idea. Maybe we should leave it to the compiler?
--
Dmitry
^ 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