* how to use the system call in the module ?
From: zjznliang @ 2005-11-16 2:19 UTC (permalink / raw)
To: linuxppc-embedded
SGkgbGludXhwcGMtZW1iZWRkZWSjoQ0KDQoJICAgICBJbiB0aGUgZGV2aWNlIGRyaXZlciwgd2Ug
YWx3YXlzIHdhbnQgdG8gc2VuZCBzb21lIGRhdGEgdG8gdGhlIGFwcGxpY2F0aW9uIC4gU28gSSB3
YXMgIHRoaW5raW5nICwgdGhlIElQQyB3b3VsZCAgZG8gbWUgYSBmYXZvciAuIEkgdXNlZCB0aGUg
c3lzX21zZ2dldCBhbmQgc3lzX21zZ3NuZCBpbiB0aGUgbW9kdWxlICxidXQgSSBnb3QgdGhpcyB3
aGVuIEkgdHlwZSB0aGUgImluc21vZCAgbW9kdWxlIiBjb21tYW5kIDoNCgkJaW5zbW9kOiB1bnJl
c29sdmVkIHN5bWJvbCBzeXNfbXNnZ2V0IA0KCQlpbnNtb2Q6IHVucmVzb2x2ZWQgc3ltYm9sIHN5
c19tc2dzbmQgDQoNCgkJSW4gbXkgb3BpbmlvbiAsdGhlIHN5c3RlbSBjYWxsIGlzIHRoZSBzeXN0
ZW0gY2FsbCB0byB0aGUgdXNlciBhcHBsaWNhdGlvbiBhbmQgdGhlIGZ1bmN0aW9uIHRvIHRoZSBr
ZXJuZWwgbW9kZSAoZWc6IG1vZHVsZSApLHNvIGhvdyB0byB1c2UgdGhlIHN5c3RlbSBjYWxsIGlu
IGtlcm5lbCBtb2RlIGlzIHRoZSB3YXkgdGhhdCBob3cgdG8gcmVjb2duaXNlIHRoZSBmdW5jdGlv
biBvZiBzeXN0ZW0gY2FsbCBpbiB0aGUgbW9kdWxlIC4NCiANCgkJQXQgdGhlIGJlZ2lubmluZywg
SSBoYWQgdG8gb3BlbiBhbmQgcmVhZCBhIGZpbGUgaW4gdGhlIG1vZHVsZSAsIHNvIEkgdXNlZCAg
dGhpcyB3YXkgdG8gYWRkIHRoZSBzeXN0ZW0gY2FsbCA6DQoNCgkJI2RlZmluZSBfS0VSTkVMX1NZ
U0NBTExTXw0KCQkjaW5jbHVkZSA8bGludXgvdW5pc3RkLmg+DQoNCgkJV2hlbiBJIHR5cGVkIHRo
ZSAiaW5zbW9kIG1vZHVsZSAiLHRoZSBzeW1ib2wgb3BlbiBhbmQgcmVhZCBjb3VsZCBiZSBmb3Vu
ZCAsYnV0IHRoZSBmdW5jdGlvbiB3YXMgbm90IGF2YWlsYWJpbGl0eS5TbyBJIGNoZWNrZWQgdGhl
IC9wcm9jL2tzeW1zIGZvciB0aGUgZnVuY3Rpb24gd2hpY2ggdGhlIGtlcm5lbCBjb3VsZCBjYWxs
ICwgYW5kIHVzZWQgdGhlIGZpbHBfb3BlbiAoKSBhbmQga2VybmVsX3JlYWQgKCkgZm9yIGluc3Rl
YWQgLg0KCQkNCgkJTm93ICwgSSBkaWQgYSB0ZXN0ICwgY29tcGlsZSB0aGUgbW9kdWxlIHdpdGgg
dGhlIGxpbnV4IGtlcm5lbCwgdGhlIHN5c19tc2dnZXQgYW5kIHN5c19tc2dzbmQgY291bGQgd29y
ayBmaW5lIC4gSSB0aG91Z2h0IHRoZSByZWFzb24gaXMgdGhhdCB0aGUgc3lzX21zZ2dldCBpcyBh
biBleHRlcm4gZnVuY3Rpb24gd2hlbiBjb21waWxpbmcgd2l0aCB0aGUga2VybmVsLlNvIHBlcmhh
cHMgLCB3aGVuIEkgZG8gaW5zbW9kIHRoZSBtb2R1bGUsIEkgZGlkIG5vdCBleHBvcnRlIHRoZSBz
eXNfbXNnZ2V0IGFuZCBzeXNfbXNnc25kIGFzIHRoZSBrZXJuZWwgc3ltYm9scy4NCg0KCQlIb3cg
dG8gZXhwb3J0ZSB0aGUgc3lzdGVtIGNhbGwgYXMgdGhlIGtlcm5lbCBzeW1ib2xzPz8gDQoNCiAg
ICAgICBBbnkgaGVscCBvbiB0aGlzIHdvdWxkIGJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIFRoYW5r
cyBmb3IgeW91ciBwYXRpZW5jZS4gDQoNCiAJCQkJDQoNCqGhoaF6anpubGlhbmcNCqGhoaGhoaGh
emp6bmxpYW5nX3BvcG9AMTYzLmNvbQ0KoaGhoaGhoaGhoaGhMjAwNS0xMS0xNg0K
^ permalink raw reply
* Re: [PATCH] powerpc: Merge align.c
From: Becky Bruce @ 2005-11-16 2:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1132032910.23979.6.camel@gaston>
Ben,
Yeah, I clearly shouldn't run testcases at 11pm, because I got in a=20
rush and only confirmed that lmw/stmw were actually taking the=20
exception. Those 2 are working beautifully. To test the others, I=20
need to run on a different board which, of course, isn't bootable at=20
the moment. As soon as I can get that up and running, I'll try some of=20=
the other cases and let you know how it goes......
BTW, Based on the pile of docs I have here, I think the list of=20
alignment-exception-causing events on FSL's current parts (603, 603e,=20
750, 74x, 74xx, e500) is:
- lmw/stmw (all procs, non-word aligned)
- single and double precision floating point ld/st ops (non-E500, non=20
data size aligned)
- dcbz to WT or CI memory (all procs)
- dcbz with cache disabled (all procs but 603e?)
- misaligned little endian accesses (603e)
- lwarx/stwcx (all procs)
- multiple/string with LE set (750, 603e, 7450, 7400)
- eciwx/ecowx (750, 7450, 7400)
- a couple of others related to vector processing
If anybody knows offhand of something missing there, let me know.
Cheers,
B
On Nov 14, 2005, at 11:35 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2005-11-14 at 23:10 -0600, Becky Bruce wrote:
> > Ben,
> >
> > I've just done some basic testing of lmw/stmw, lwz/stw, lhx/sth,
> > lfs/stfs, and lfd/stfd misaligned across a doubleword boundary, and
> > everything looks good so far.=A0=A0 I'll check out the byte =
reversals=20
> and a
> > few other forms tomorrow.
>
> Excellent, thanks ! BTW. Make sure you test these one CPUs that=20
> actually
> trap on misaligned accesses :) Best is probably to do the misaligned
> access accross a page boundary, that's what most CPUs can do.
>
> Ben.
>
^ permalink raw reply
* Re: U-Boot
From: Wolfgang Denk @ 2005-11-16 1:06 UTC (permalink / raw)
To: mcnernbm; +Cc: linuxppc-embedded
In-Reply-To: <OF3D06561E.1EB2655E-ON852570BB.00015870-852570BB.00016F3F@notes.udayton.edu>
In message <OF3D06561E.1EB2655E-ON852570BB.00015870-852570BB.00016F3F@notes.udayton.edu> you wrote:
>
> I have a question about U-Boot. I have a board with no flash capability
> at all. Will u-boot work on a xilinx board with no flash and only sdram?
> Can uboot be downloaded into sdram and used to boot linux?
> Thanks
> Brett
> --=_alternative 00016F3D852570BB_=
> Content-Type: text/html; charset="US-ASCII"
One questions, three goof-ups.
1) This is the linuxppc-embedded list. U-Boot related questions are
off topic here and should be posted to u-boot-users instead.
2) The answers to your questions are "yes" and "yes", but you posted
without reading the FAQ. See especially
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
3) Please don't post HTML to public mailing lists.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Today is the yesterday you worried about tomorrow.
^ permalink raw reply
* U-Boot
From: mcnernbm @ 2005-11-16 0:15 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 220 bytes --]
I have a question about U-Boot. I have a board with no flash capability
at all. Will u-boot work on a xilinx board with no flash and only sdram?
Can uboot be downloaded into sdram and used to boot linux?
Thanks
Brett
[-- Attachment #2: Type: text/html, Size: 361 bytes --]
^ permalink raw reply
* Re: Problem:-BDI(u-boot) programming on MPC 8272ADS
From: Federico Lucifredi @ 2005-11-16 0:00 UTC (permalink / raw)
To: srideep.devireddy; +Cc: linuxppc-embedded
In-Reply-To: <6AD9F6A5F6E096408F0B703773355A0751AC41@CHN-SNR-MBX01.wipro.com>
Srideep,
I have never used the BDI 2000 with the MPC8272, however, I can tell
you that configuring your emulator for your specific board, if the
manufacturer does not provide a *verified* configuration for it, is
something that takes some time and a few variables to tweak.
Maybe you can expect to find a configuration ready made for some
Motorola prototype board like the ADS 8272, *but* it would be a mistake
to assume that that maps directly to your hardware in a workable manner.
Bottom line, you need to know exactly what all of the emulator knobs
are, and, if this is new hardware, keep in mind that it [the new
hardware] could be malfunctioning. Do not assume the hardware is
operating as a reliable computer unless you have positive proof that is
the case - my personal experience is that I tried to make an emulator
work on hardware that someone above me kept insisting "had to be
working" - which was not the case. I got plenty of frustration and
nothing to show for it - I should have defended the case that the
hardware was not working much harder than I did 8)
Anyway.. I am digressing. How is your BDI 2000 behaving ? I was using
an "Embedded Toolsmiths" emulator, by the way.
-f
On Wed, 2005-10-12 at 17:14 +0530, srideep.devireddy@wipro.com wrote:
> Hi ,
>
> I am srideep , we have problem in programming flash on MPC 8272
> ADS file using BDI 2000 with linux as host. As I am new to this I
> need your help in this regard.
>
>
>
> We have connected the BDI2000 to MPC8272ADS board. We are working on
> linux & I have attached configuration file for 8272 ADS board .
>
> BDI 2000 could recognize the processor type.
>
> But when we try to program the flash (with uboot binary image ) at
> location 0xff800000 on MPC 8272ADS evaluation board, it failed to
> program,
>
> We tried to unlock and do the same but still left with the same error.
>
> But when we tried to program in any other location it programmed but
> it doesnt boot .
>
> Can you kindly send us the working configuration file.
>
>
>
>
>
> Thanks & Regards
>
> Srideep Reddy D
>
> Software Engineer
>
> Telecom solutions
>
> Wipro Technologies
>
> 91-44-30691952
>
>
>
>
>
>
> Confidentiality Notice
>
> The information contained in this electronic message and any
> attachments to this message are intended
> for the exclusive use of the addressee(s) and may contain confidential
> or privileged information. If
> you are not the intended recipient, please notify the sender at Wipro
> or Mailadmin@wipro.com immediately
> and destroy all copies of this message and any attachments.
>
^ permalink raw reply
* Re: Platform device model drawback
From: Greg KH @ 2005-11-15 22:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded list
In-Reply-To: <Pine.LNX.4.44.0511151332310.28098-100000@gate.crashing.org>
On Tue, Nov 15, 2005 at 01:34:47PM -0600, Kumar Gala wrote:
> > You only register the driver once. The individual devices can be bound
> > to the same driver, right?
> >
> > > Not registering it in CPM_UART, how the pdev could be obtained?
> > >
> > > Maybe this is clear, but platform stuff is cumbersome some times...
> >
> > Then make it cleaner :)
>
> This is where the confusion is. We have two instances of device A. We
> want instance 1 of device A bound to driver "enet" and instance 2 of
> device A bound to "serial".
That's different from what was described earlier :)
In this case, you need two different struct devices.
> Today both instances are called "deviceA". However we can't register two
> different drivers as "deviceA".
Nor would you want to.
> Not sure if that clarifies the issue any.
A bit. I think it still sounds messy...
thanks,
greg k-h
^ permalink raw reply
* Re: modify the cache-inhibit and guard bits from userspace?
From: Christopher Friesen @ 2005-11-15 23:15 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc64-dev, linuxppc-embedded
In-Reply-To: <200511152338.53238.arnd@arndb.de>
Arnd Bergmann wrote:
> I have seen an earlier patch that modifies madvise to do this, which seems
> a little saner than mprotect, although they can probably both be implemented
> in a similar way.
Ah, that would make sense. It does fit the intent of the function a bit
better.
> Alternatively, you could write a new file system similar to hugetlbfs and set
> the cache-inhibit bit in its mmap function.
Also a possibility. I think the madvise method is a bit cleaner for the
apps.
Chris
^ permalink raw reply
* Re: modify the cache-inhibit and guard bits from userspace?
From: Arnd Bergmann @ 2005-11-15 22:38 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: Christopher Friesen, linuxppc-embedded
In-Reply-To: <437A5049.9090308@nortel.com>
Am Dienstag 15 November 2005 22:16 schrieb Christopher Friesen:
> What's the most logical way for me to do this? =A0Do I extend mprotect()
> to support additional flags?
>
> Has anyone done this before? =A0I didn't find anything in google.
> Currently the guard bit seems to only be used for ioremap() and in
> __pci_mmap_set_pgprot() if the memory doesn't support write combining.
I have seen an earlier patch that modifies madvise to do this, which seems
a little saner than mprotect, although they can probably both be implemented
in a similar way.
Alternatively, you could write a new file system similar to hugetlbfs and s=
et=20
the cache-inhibit bit in its mmap function.
Arnd <><
^ permalink raw reply
* modify the cache-inhibit and guard bits from userspace?
From: Christopher Friesen @ 2005-11-15 21:16 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-embedded
We're running a dual-970 blade, based on a modified 2.6.10.
We have an application that does lots of random data fetches over a
fairly large data set (a few GB) contained entirely in RAM, and the
performance guys think that we may be spending time in unnecessary
hardware prefetches and would like me to provide them a mechanism to
individually specify the cache-inhibited and guard bits from userspace
so that they can try to fine-tune their performance.
What's the most logical way for me to do this? Do I extend mprotect()
to support additional flags?
Has anyone done this before? I didn't find anything in google.
Currently the guard bit seems to only be used for ioremap() and in
__pci_mmap_set_pgprot() if the memory doesn't support write combining.
Thanks,
Chris
^ permalink raw reply
* Re: Platform device model drawback
From: Andy Fleming @ 2005-11-15 19:43 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-embedded list
In-Reply-To: <20051115175955.GA14518@kroah.com>
On Nov 15, 2005, at 11:59, Greg KH wrote:
> > I have for instance struct device_driver with name="fsl-cpm-scc"
> in both
> > fs_enet and cpm_uart(one using SCC1, the other - SCC4, the same
> device with
> > different id's).
> >
> > Once it has been registered in fs_enet, I could not register it in
> > cpm_uart, due to kobject_register fo require unique names in
> kobject->name.
> > Am I missing something?
>
> You only register the driver once. The individual devices can be
> bound
> to the same driver, right?
>
> > Not registering it in CPM_UART, how the pdev could be obtained?
> >
> > Maybe this is clear, but platform stuff is cumbersome some times...
>
> Then make it cleaner :)
>
> If you have specific code that explains this better, that might help
> out.
>
So the problem Vitaly is referring to is that the CPM is somewhat
programmable. The SCC (Serial Communications Controller) is capable
of being used as a uart, or as an ethernet device, depending on
software configuration. Currently, most systems I'm aware of
configure this at boot time, depending on how the kernel has been
configured. So the same SOC may have SCC1 as a uart on one board,
but as an ethernet controller on another board.
I believe there is work being done to clean this up, and make it more
flexible. As a temporary solution, we might want to declare 8
different devices. Something like "cpm-scc-uart", and "cpm-scc-
enet". And then create SCC1-4 twice, and let the board code delete
the devices that aren't going to be used.
Andy
^ permalink raw reply
* Re: Platform device model drawback
From: Andrey Volkov @ 2005-11-15 19:41 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: Greg KH, linuxppc-embedded list
In-Reply-To: <437A21EA.5020507@ru.mvista.com>
Vitaly Bordug wrote:
> Greg KH wrote:
>
>> On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
>>
>>> Hi, Greg!
>>>
>>> While doing "platformization" for one of the Freescale SoC's, I have
>>> discovered a serious drawback of the model - it prevents registering
>>> driver with the same name.
>>
>>
>> That's not a "drawback" :)
>>
>>> For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and
>>> its device fsl-cpm-scc could (and actually are) utilized in the
>>> different drivers.
>>>
>>> Those devices will have different bus_id, but pdev->name fields are
>>> the same for all the fsl-cpm-scc, only id is different there. Hence
>>> the fsl-cpm-scc could be driver_register'ed only once, while it is
>>> required several times.
>>
>>
>> A driver is registered only once, but can be bound to multiple devices
>> just fine, right?
>
> Please let me know, how?
>
> I have for instance struct device_driver with name="fsl-cpm-scc" in both
> fs_enet and cpm_uart(one using SCC1, the other - SCC4, the same device
> with different id's).
>
> Once it has been registered in fs_enet, I could not register it in
> cpm_uart, due to kobject_register fo require unique names in
> kobject->name. Am I missing something?
May be better to convert fsl-cpm-scc to BUS driver which will be
derived from platform_driver? In this case you'll get flexible
SCCx enumerator as bonus.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: Platform device model drawback
From: Kumar Gala @ 2005-11-15 19:34 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-embedded list
In-Reply-To: <20051115175955.GA14518@kroah.com>
> You only register the driver once. The individual devices can be bound
> to the same driver, right?
>
> > Not registering it in CPM_UART, how the pdev could be obtained?
> >
> > Maybe this is clear, but platform stuff is cumbersome some times...
>
> Then make it cleaner :)
This is where the confusion is. We have two instances of device A. We
want instance 1 of device A bound to driver "enet" and instance 2 of
device A bound to "serial".
Today both instances are called "deviceA". However we can't register two
different drivers as "deviceA".
Not sure if that clarifies the issue any.
- kumar
^ permalink raw reply
* Re: [PATCH] m8xx_wdt: software watchdog reset/interrupt select
From: Marcelo Tosatti @ 2005-11-15 14:21 UTC (permalink / raw)
To: Florian Schirmer; +Cc: obi, carjay, linux-ppc-embedded
In-Reply-To: <20051115054216.GB29963@logos.cnet>
On Tue, Nov 15, 2005 at 03:42:16AM -0200, Marcelo Tosatti wrote:
> Hi Florian!
>
> On Tue, Nov 15, 2005 at 07:41:43AM +0100, Florian Schirmer wrote:
> > Hi,
> >
> > >Note: From my reading of the documentation, even if the SWRI bit is
> > >unset (interrupt select mode), an NMI at IRQ0 should cause the system to
> > >jump to exception vector 0x100, resetting the system.
> > >
> > >So I'm wondering if the interrupt mode ever worked?
> >
> > Never tried the interrupt mode. IMHO doesn't make much sense for a
> > watchdog. Why don't you simply set SWRI?
>
> The SYPCR register can be set only _once_ at machine startup and the
> bootloader in question does not have an option to change the mode. Many
> bootloaders probably dont.
>
> > >+static void m8xx_wdt_timer_func(unsigned long data)
> > >+{
> > >+ m8xx_wdt_reset();
> > >+ m8xx_wdt_timer.expires = jiffies + 25;
> > >+ add_timer(&m8xx_wdt_timer);
> > >+}
> > >+
> > >+void m8xx_wdt_install_timer(volatile immap_t *imap)
> > >+{
> > >+ m8xx_wdt_timer.expires = jiffies + 25;
> > >+ add_timer(&m8xx_wdt_timer);
> > >+}
> >
> > m8xx_wdt_install_timer doesn't need imap and you could call it from
> > m8xx_wdt_timer_func to re-engange the timer resulting in less duplicated
> > code. Just a cosmetic thing though.
>
> Indeed. Will update the patch and resend you for review.
Florian,
Updated patch addresses code duplication issue you mentioned and also
adds an error message in case timer interrupt frequency is higher
than the watchdog frequency.
Can I add your Signed-off-by in case you're OK with it?
diff --git a/arch/ppc/syslib/m8xx_wdt.c b/arch/ppc/syslib/m8xx_wdt.c
index a21632d..d73f8db 100644
--- a/arch/ppc/syslib/m8xx_wdt.c
+++ b/arch/ppc/syslib/m8xx_wdt.c
@@ -45,35 +45,18 @@ static irqreturn_t m8xx_wdt_interrupt(in
return IRQ_HANDLED;
}
-void __init m8xx_wdt_handler_install(bd_t * binfo)
+#define SYPCR_SWP 0x1
+#define SYPCR_SWRI 0x2
+#define SYPCR_SWE 0x4
+
+/* software watchdog reset/interrupt select */
+int m8xx_wdt_keepalive_mode = 0;
+
+void __init m8xx_wdt_install_irq(volatile immap_t *imap, bd_t *binfo)
{
- volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
u32 pitc;
- u32 sypcr;
u32 pitrtclk;
- sypcr = in_be32(&imap->im_siu_conf.sc_sypcr);
-
- if (!(sypcr & 0x04)) {
- printk(KERN_NOTICE "m8xx_wdt: wdt disabled (SYPCR: 0x%08X)\n",
- sypcr);
- return;
- }
-
- m8xx_wdt_reset();
-
- printk(KERN_NOTICE
- "m8xx_wdt: active wdt found (SWTC: 0x%04X, SWP: 0x%01X)\n",
- (sypcr >> 16), sypcr & 0x01);
-
- wdt_timeout = (sypcr >> 16) & 0xFFFF;
-
- if (!wdt_timeout)
- wdt_timeout = 0xFFFF;
-
- if (sypcr & 0x01)
- wdt_timeout *= 2048;
-
/*
* Fire trigger if half of the wdt ticked down
*/
@@ -98,6 +81,65 @@ void __init m8xx_wdt_handler_install(bd_
printk(KERN_NOTICE
"m8xx_wdt: keep-alive trigger installed (PITC: 0x%04X)\n", pitc);
+}
+
+static void m8xx_wdt_timer_func(unsigned long data);
+
+static struct timer_list m8xx_wdt_timer =
+ TIMER_INITIALIZER(m8xx_wdt_timer_func, 0, 0);
+
+void m8xx_wdt_stop_timer(void)
+{
+ del_timer(&m8xx_wdt_timer);
+}
+
+void m8xx_wdt_install_timer(void)
+{
+ m8xx_wdt_timer.expires = jiffies + (HZ/2);
+ add_timer(&m8xx_wdt_timer);
+}
+
+static void m8xx_wdt_timer_func(unsigned long data)
+{
+ m8xx_wdt_reset();
+ m8xx_wdt_install_timer();
+}
+
+void __init m8xx_wdt_handler_install(bd_t * binfo)
+{
+ volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
+ u32 sypcr;
+
+ sypcr = in_be32(&imap->im_siu_conf.sc_sypcr);
+
+ if (!(sypcr & SYPCR_SWE)) {
+ printk(KERN_NOTICE "m8xx_wdt: wdt disabled (SYPCR: 0x%08X)\n",
+ sypcr);
+ return;
+ }
+
+ m8xx_wdt_reset();
+
+ printk(KERN_NOTICE
+ "m8xx_wdt: active wdt found (SWTC: 0x%04X, SWP: 0x%01X)\n",
+ (sypcr >> 16), sypcr & SYPCR_SWP);
+
+ wdt_timeout = (sypcr >> 16) & 0xFFFF;
+
+ if (!wdt_timeout)
+ wdt_timeout = 0xFFFF;
+
+ if (sypcr & SYPCR_SWP)
+ wdt_timeout *= 2048;
+
+ m8xx_wdt_keepalive_mode = sypcr & SYPCR_SWRI;
+ if (m8xx_wdt_keepalive_mode) {
+ if (wdt_timeout < (binfo->bi_intfreq/HZ))
+ printk(KERN_ERR "m8xx_wdt: timeout too short for ktimer!\n");
+ m8xx_wdt_install_timer();
+ } else
+ m8xx_wdt_install_irq(imap, binfo);
+
wdt_timeout /= binfo->bi_intfreq;
}
diff --git a/arch/ppc/syslib/m8xx_wdt.h b/arch/ppc/syslib/m8xx_wdt.h
index 0d81a9f..c9ee9d7 100644
--- a/arch/ppc/syslib/m8xx_wdt.h
+++ b/arch/ppc/syslib/m8xx_wdt.h
@@ -9,8 +9,12 @@
#ifndef _PPC_SYSLIB_M8XX_WDT_H
#define _PPC_SYSLIB_M8XX_WDT_H
+extern int m8xx_wdt_keepalive_mode;
+
extern void m8xx_wdt_handler_install(bd_t * binfo);
extern int m8xx_wdt_get_timeout(void);
extern void m8xx_wdt_reset(void);
+extern void m8xx_wdt_install_timer(void);
+extern void m8xx_wdt_stop_timer(void);
#endif /* _PPC_SYSLIB_M8XX_WDT_H */
diff --git a/drivers/char/watchdog/mpc8xx_wdt.c b/drivers/char/watchdog/mpc8xx_wdt.c
index 56d62ba..8ffa744 100644
--- a/drivers/char/watchdog/mpc8xx_wdt.c
+++ b/drivers/char/watchdog/mpc8xx_wdt.c
@@ -27,7 +27,10 @@ static void mpc8xx_wdt_handler_disable(v
{
volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
- imap->im_sit.sit_piscr &= ~(PISCR_PIE | PISCR_PTE);
+ if (m8xx_wdt_keepalive_mode)
+ m8xx_wdt_stop_timer();
+ else
+ imap->im_sit.sit_piscr &= ~(PISCR_PIE | PISCR_PTE);
printk(KERN_NOTICE "mpc8xx_wdt: keep-alive handler deactivated\n");
}
@@ -36,7 +39,10 @@ static void mpc8xx_wdt_handler_enable(vo
{
volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
- imap->im_sit.sit_piscr |= PISCR_PIE | PISCR_PTE;
+ if (m8xx_wdt_keepalive_mode)
+ m8xx_wdt_install_timer();
+ else
+ imap->im_sit.sit_piscr |= PISCR_PIE | PISCR_PTE;
printk(KERN_NOTICE "mpc8xx_wdt: keep-alive handler activated\n");
}
^ permalink raw reply related
* Re: Platform device model drawback
From: Greg KH @ 2005-11-15 17:59 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <437A21EA.5020507@ru.mvista.com>
On Tue, Nov 15, 2005 at 08:59:06PM +0300, Vitaly Bordug wrote:
> Greg KH wrote:
> >On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
> >>Hi, Greg!
> >>
> >>While doing "platformization" for one of the Freescale SoC's, I have
> >>discovered a serious drawback of the model - it prevents registering
> >>driver with the same name.
> >
> >That's not a "drawback" :)
> >
> >>For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and
> >>its device fsl-cpm-scc could (and actually are) utilized in the
> >>different drivers.
> >>
> >>Those devices will have different bus_id, but pdev->name fields are the
> >>same for all the fsl-cpm-scc, only id is different there. Hence the
> >>fsl-cpm-scc could be driver_register'ed only once, while it is required
> >>several times.
> >
> >A driver is registered only once, but can be bound to multiple devices
> >just fine, right?
> Please let me know, how?
All PCI and USB and I2C drivers are able to bind to multiple devices :)
> I have for instance struct device_driver with name="fsl-cpm-scc" in both
> fs_enet and cpm_uart(one using SCC1, the other - SCC4, the same device with
> different id's).
>
> Once it has been registered in fs_enet, I could not register it in
> cpm_uart, due to kobject_register fo require unique names in kobject->name.
> Am I missing something?
You only register the driver once. The individual devices can be bound
to the same driver, right?
> Not registering it in CPM_UART, how the pdev could be obtained?
>
> Maybe this is clear, but platform stuff is cumbersome some times...
Then make it cleaner :)
If you have specific code that explains this better, that might help
out.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1 kernel 2.6.15-rc1] Fix copy-paste bug after _Convert platform drivers to use_ (again)
From: Russell King @ 2005-11-15 19:06 UTC (permalink / raw)
To: Andrey Volkov; +Cc: linux-kernel, ML linuxppc-embedded
In-Reply-To: <437A2EE8.4050404@varma-el.com>
On Tue, Nov 15, 2005 at 09:54:32PM +0300, Andrey Volkov wrote:
> Hello Russell,
>
> I fear it is not a last patch of such kind :(.
> Please recheck places where you are changed
> pdev<->dev.
Either that will have to wait a number of days or someone else will
have to do that. I'm sorry but I'm rather unwell and in no fit state
to do anything major with kernels atm.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
^ permalink raw reply
* [PATCH 1/1 kernel 2.6.15-rc1] Fix copy-paste bug after _Convert platform drivers to use_ (again)
From: Andrey Volkov @ 2005-11-15 18:54 UTC (permalink / raw)
To: Russell King; +Cc: linux-kernel, ML linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 147 bytes --]
Hello Russell,
I fear it is not a last patch of such kind :(.
Please recheck places where you are changed
pdev<->dev.
--
Regards
Andrey Volkov
[-- Attachment #2: ohci-ohci-ppc-soc.diff --]
[-- Type: text/plain, Size: 597 bytes --]
Fix copy-paste bug in ohci-ppc-soc.c(ohci_hcd_ppc_soc_drv_remove)
Sign-off-by: Andrey Volkov <avolkov@varma-el.com>
---
diff --git a/drivers/usb/host/ohci-ppc-soc.c b/drivers/usb/host/ohci-ppc-soc.c
index 1875576..2ec6a78 100644
--- a/drivers/usb/host/ohci-ppc-soc.c
+++ b/drivers/usb/host/ohci-ppc-soc.c
@@ -185,7 +185,7 @@ static int ohci_hcd_ppc_soc_drv_probe(st
static int ohci_hcd_ppc_soc_drv_remove(struct platform_device *pdev)
{
- struct usb_hcd *hcd = platform_get_drvdata(dev);
+ struct usb_hcd *hcd = platform_get_drvdata(pdev);
usb_hcd_ppc_soc_remove(hcd, pdev);
return 0;
^ permalink raw reply related
* [PATCH 1/1 kernel 2.6.15-rc1] Fix copy-paste bug after _Convert platform drivers to use_ (again)
From: Andrey Volkov @ 2005-11-15 18:53 UTC (permalink / raw)
To: Russell King; +Cc: linux-kernel, ML linuxppc-embedded
Hello Russell,
I fear it is not a last patch of such kind :(.
Please recheck places where you are changed
pdev<->dev.
--
Regards
Andrey Volkov
^ permalink raw reply
* Re: Linuv 2.6.15-rc1
From: Olaf Hering @ 2005-11-15 18:53 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linux Kernel Mailing List, ppc-dev list, Linus Torvalds,
Michael Buesch
In-Reply-To: <1131915560.5504.67.camel@gaston>
On Mon, Nov 14, Benjamin Herrenschmidt wrote:
> On Sun, 2005-11-13 at 10:37 -0600, Kumar Gala wrote:
>
> > Can we please add some defconfigs for arch/powerpc to possibly help
> > with this issue. I'm think a pmac32, pmac64, and whatever other 64
> > bit configs would be a good start.
>
> The 64 bits defconfigs are there already. I'll do a pmac one.
Can you move also arch/ppc64/defconfig into arch/powerpc/configs/?
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: Platform device model drawback
From: Vitaly Bordug @ 2005-11-15 17:59 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-embedded list
In-Reply-To: <20051115165532.GB12968@kroah.com>
Greg KH wrote:
> On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
>> Hi, Greg!
>>
>> While doing "platformization" for one of the Freescale SoC's, I have
>> discovered a serious drawback of the model - it prevents registering
>> driver with the same name.
>
> That's not a "drawback" :)
>
>> For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and
>> its device fsl-cpm-scc could (and actually are) utilized in the
>> different drivers.
>>
>> Those devices will have different bus_id, but pdev->name fields are the
>> same for all the fsl-cpm-scc, only id is different there. Hence the
>> fsl-cpm-scc could be driver_register'ed only once, while it is required
>> several times.
>
> A driver is registered only once, but can be bound to multiple devices
> just fine, right?
Please let me know, how?
I have for instance struct device_driver with name="fsl-cpm-scc" in both fs_enet and
cpm_uart(one using SCC1, the other - SCC4, the same device with different id's).
Once it has been registered in fs_enet, I could not register it in cpm_uart, due to
kobject_register fo require unique names in kobject->name. Am I missing something?
Not registering it in CPM_UART, how the pdev could be obtained?
Maybe this is clear, but platform stuff is cumbersome some times...
>
>> Could you please suggest possible solutions for this situation? This is
>> relatively common case among freescale chips, so I guess inventing a
>> workaround is odd, and writing an additional shim to handle CPM device
>> multiplexing is odd either.
>
> I don't see the problem here. Are you looking at the new stuff in
> 2.6.15-rc1?
>
Yes, sort of. I am going to add 8xx IRDA and make cpm_uart platform device model compatible.
> thanks,
>
> greg k-h
>
>
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Platform device model drawback
From: Greg KH @ 2005-11-15 16:55 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded list
In-Reply-To: <437A1208.2060804@ru.mvista.com>
On Tue, Nov 15, 2005 at 07:51:20PM +0300, Vitaly Bordug wrote:
> Hi, Greg!
>
> While doing "platformization" for one of the Freescale SoC's, I have
> discovered a serious drawback of the model - it prevents registering
> driver with the same name.
That's not a "drawback" :)
> For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and
> its device fsl-cpm-scc could (and actually are) utilized in the
> different drivers.
>
> Those devices will have different bus_id, but pdev->name fields are the
> same for all the fsl-cpm-scc, only id is different there. Hence the
> fsl-cpm-scc could be driver_register'ed only once, while it is required
> several times.
A driver is registered only once, but can be bound to multiple devices
just fine, right?
> Could you please suggest possible solutions for this situation? This is
> relatively common case among freescale chips, so I guess inventing a
> workaround is odd, and writing an additional shim to handle CPM device
> multiplexing is odd either.
I don't see the problem here. Are you looking at the new stuff in
2.6.15-rc1?
thanks,
greg k-h
^ permalink raw reply
* [PATCH] powerpc: add new powerbooks to feature table
From: Olof Johansson @ 2005-11-15 17:05 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Hi,
The previous PowerBook patch didn't contain the feature table updates
for ARCH=powerpc. Here they are.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: linux-2.6/arch/powerpc/platforms/powermac/feature.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/powermac/feature.c 2005-11-15 00:05:28.000000000 -0800
+++ linux-2.6/arch/powerpc/platforms/powermac/feature.c 2005-11-15 00:05:59.000000000 -0800
@@ -2362,6 +2362,14 @@ static struct pmac_mb_def pmac_mb_defs[]
PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
},
+ { "PowerBook5,8", "PowerBook G4 15\"",
+ PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
+ PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
+ },
+ { "PowerBook5,9", "PowerBook G4 17\"",
+ PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
+ PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
+ },
{ "PowerBook6,1", "PowerBook G4 12\"",
PMAC_TYPE_UNKNOWN_INTREPID, intrepid_features,
PMAC_MB_MAY_SLEEP | PMAC_MB_HAS_FW_POWER | PMAC_MB_MOBILE,
^ permalink raw reply
* [PATCH] powerpc: replace page_to_virt() with lowmem_page_address() for Book-E
From: Kumar Gala @ 2005-11-15 17:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev, linuxppc-embedded
page_to_virt and lowmem_page_address provided equiavlent functionality
so use the more standard lowmem_page_address
This also addresses build issue in ARCH=powerpc since page_to_virt()
has been removed from include/asm-powerpc/page.h
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit bd544f8830a563d50d58970c9360379efc555641
tree 887891cdf18bef998f5b5a5ffff9b879ff3591db
parent 1b5b521b837ee0a9366a0750d915e09566229be4
author Kumar Gala <galak@kernel.crashing.org> Tue, 15 Nov 2005 11:03:34 -0600
committer Kumar Gala <galak@kernel.crashing.org> Tue, 15 Nov 2005 11:03:34 -0600
include/asm-ppc/pgalloc.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/asm-ppc/pgalloc.h b/include/asm-ppc/pgalloc.h
index 931b6de..bdefd1c 100644
--- a/include/asm-ppc/pgalloc.h
+++ b/include/asm-ppc/pgalloc.h
@@ -28,7 +28,7 @@ extern void pgd_free(pgd_t *pgd);
#define pmd_populate_kernel(mm, pmd, pte) \
(pmd_val(*(pmd)) = (unsigned long)pte | _PMD_PRESENT)
#define pmd_populate(mm, pmd, pte) \
- (pmd_val(*(pmd)) = (unsigned long)page_to_virt(pte) | _PMD_PRESENT)
+ (pmd_val(*(pmd)) = (unsigned long)lowmem_page_address(pte) | _PMD_PRESENT)
#endif
extern pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long addr);
^ permalink raw reply related
* Platform device model drawback
From: Vitaly Bordug @ 2005-11-15 16:51 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-embedded list
Hi, Greg!
While doing "platformization" for one of the Freescale SoC's, I have
discovered a serious drawback of the model - it prevents registering
driver with the same name.
For instance, cpm2 on either ppc82xx or ppc85xx is very flexible, and
its device fsl-cpm-scc could (and actually are) utilized in the
different drivers.
Those devices will have different bus_id, but pdev->name fields are the
same for all the fsl-cpm-scc, only id is different there. Hence the
fsl-cpm-scc could be driver_register'ed only once, while it is required
several times.
Could you please suggest possible solutions for this situation? This is
relatively common case among freescale chips, so I guess inventing a
workaround is odd, and writing an additional shim to handle CPM device
multiplexing is odd either.
TIA!
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: [PATCH] powerpc: put page page_to_virt for Book-e processors
From: Kumar Gala @ 2005-11-15 16:45 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <20051115092042.GA2060@lst.de>
On Tue, 15 Nov 2005, Christoph Hellwig wrote:
> On Mon, Nov 14, 2005 at 05:21:44PM -0600, Kumar Gala wrote:
> > Book-E processors use page_to_virt since we have to always translate.
>
> Why can't you use the proper page_address() macro?
I really want is lowmem_page_address() since the only current ppc user of
page_to_virt() in include/asm-ppc/pgalloc.h is pmd_populate() for book-e.
We have to have pages in lowmem.
- kumar
^ permalink raw reply
* Re: MPC8555 USB host support
From: Vitaly Bordug @ 2005-11-15 15:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <D95D5881-250C-4B54-BD5A-54C79D9E0496@kernel.crashing.org>
Kumar Gala wrote:
> Any reason not to get this driver into the kernel main line?
I guess because this device is known to work in some specific instance,
but bot generic one. The best we can do is to consolidate our efforts to
make it more usable or state that it is impossible.
>
> - kumar
>
> On Nov 15, 2005, at 12:59 AM, Mike Rapoport wrote:
>
>> Hans Schillstrom wrote:
>>
>>> Hi Mike
>>> I'm working with a 8270 board and 2.6.12 kernel and searching for USB
>>> drivers.
>>>
>>> Could you help me finding the files ?
>>>
>> I've opened a project on the SourceForge,
>> http://cpm2usb.sourceforge.net. The file containing patch against
>> 2.6.12.3 can be downloaded at http://sourceforge.net/projects/cpm2usb.
>>
>>> I can help you with the testing.
>>> What status do they have right now ?
>>>
>> The driver was developed on MPC8272ADS, but should go as well on 8270
>> since they have the same USB host controller AFAIK.
>> Currently, as far as I tested it works fine with full-speed single
>> device attached through hub, but fails is there are transfers from/to
>> several devices simultaneously.
>> As for the code itself, it's far from being perfect.
>>
>>> Regards Hans
>>>
>>
>>
>> --Sincerely yours,
>> Mike Rapoport
>>
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
Sincerely,
Vitaly
^ 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