Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Paul Mackerras schrieb: > Andrew Morton writes: > >> Bizarrely, the original author of the patch (Anton) has fallen off the cc. >> Could whoever did that please thwap himself? >> >> Anyway, my head is now officially spinning. Did anyone actually have a >> reason why we shouldn't proceed with Anton's patch? > > I was wondering if it would be sufficient to provide alternative > versions of fb_readl, fb_writel etc. that do byte-swapping. That > would mean that all framebuffers would have to have the same > endianness, but that would suffice for embedded systems such as > Anton's and would end up a lot simpler IMHO. Yes. At least the affected PowerPC platforms can do byte-swapping on the fly, so this should be sufficient and without performance penalty, AFAICS. Regards, Clemens ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Andrew Morton schrieb: > On Tue, 19 Feb 2008 12:27:54 +0100 Clemens Koller <[EMAIL PROTECTED]> wrote: >> Benjamin Herrenschmidt schrieb: >>> On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote: >>>> [EMAIL PROTECTED] schrieb: >>>>> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: >>>>>> I know two fb drivers which use endianess information (pm2fb and >>>>>> s3c2410fb). >>>>>> Both resolve endianess at driver level. Actually, both handle it by >>>>>> setting special >>>>>> bits so the graphics chip itself reorder bytes to transform foreign >>>>>> endianess. >>>>>> I understand that this patch is for chips which cannot reorder bytes by >>>>>> themselves. >>>>> Does anybody know of such a chip that's actually available in the wild? >>>>> Or are >>>>> we writing drivers for speculative possible chips? >>>>> >>>> I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC >>>> PCI vs. LocalBus. >>>> The chip also has a register to swap endianess, but that seems to only >>>> affect some >>>> LocalBus modes. >>>> The current fb and X drivers are working, but when it comes to font >>>> aliasing and hw-acceleration, the problems start to rise again... >>> Most "sane" gfx chips nowadays provide configurable surfaces that allow >>> to perform the swap when writing/reading from regions of the >>> framebuffer, with the ability to set a different swapper setting (based >>> on bit depth) per region. >> Most! But not the SM50x. I still hope I would be wrong here. :-( >> >>> Then there is also the risk that your PCI<->Localbus has been wired >>> improperly :-) >> That's not an issue in my case. The SM50x can be connected to >> either an PCI or some Local/CPU-whateverbus IF. >> I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses. >> If the sm501 is attached to the MPC85xx' PCI like any other video card, >> the PCI config-space is can be accessed as usual, whereas the framebuffer >> memory area is byte-swapped compared to other common video cards. >> >> So, to get back on topic: >> I would welcome endianess swapping in SW. Some architectures (PowerPC) >> should also be able to do swapped-endian mmapping. I just haven't >> had time for a closer look but it looks also interesting way to do it >> that way. > > Bizarrely, the original author of the patch (Anton) has fallen off the cc. > Could whoever did that please thwap himself? Propably my bad, being subscribed to several CCed lists... > Anyway, my head is now officially spinning. Did anyone actually have a > reason why we shouldn't proceed with Anton's patch? Since it seem that there are some odd chips out in the wild, I guess Valdis (also readded to CC:) has no more objections to give it a try. :-) Regards, Clemens ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
Benjamin Herrenschmidt schrieb: > On Tue, 2008-02-19 at 00:35 +0100, Clemens Koller wrote: >> [EMAIL PROTECTED] schrieb: >>> On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: >>>> I know two fb drivers which use endianess information (pm2fb and >>>> s3c2410fb). >>>> Both resolve endianess at driver level. Actually, both handle it by >>>> setting special >>>> bits so the graphics chip itself reorder bytes to transform foreign >>>> endianess. >>>> I understand that this patch is for chips which cannot reorder bytes by >>>> themselves. >>> Does anybody know of such a chip that's actually available in the wild? Or >>> are >>> we writing drivers for speculative possible chips? >>> >> I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI >> vs. LocalBus. >> The chip also has a register to swap endianess, but that seems to only >> affect some >> LocalBus modes. >> The current fb and X drivers are working, but when it comes to font >> aliasing and hw-acceleration, the problems start to rise again... > > Most "sane" gfx chips nowadays provide configurable surfaces that allow > to perform the swap when writing/reading from regions of the > framebuffer, with the ability to set a different swapper setting (based > on bit depth) per region. Most! But not the SM50x. I still hope I would be wrong here. :-( > Then there is also the risk that your PCI<->Localbus has been wired > improperly :-) That's not an issue in my case. The SM50x can be connected to either an PCI or some Local/CPU-whateverbus IF. I.e. on the MPC85xx PowerPC, PCI and LocalBus are separate bussses. If the sm501 is attached to the MPC85xx' PCI like any other video card, the PCI config-space is can be accessed as usual, whereas the framebuffer memory area is byte-swapped compared to other common video cards. So, to get back on topic: I would welcome endianess swapping in SW. Some architectures (PowerPC) should also be able to do swapped-endian mmapping. I just haven't had time for a closer look but it looks also interesting way to do it that way. Regards, Clemens ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness
[EMAIL PROTECTED] schrieb: > On Mon, 18 Feb 2008 08:18:47 +0100, Krzysztof Helt said: >> I know two fb drivers which use endianess information (pm2fb and s3c2410fb). >> Both resolve endianess at driver level. Actually, both handle it by setting >> special >> bits so the graphics chip itself reorder bytes to transform foreign >> endianess. >> I understand that this patch is for chips which cannot reorder bytes by >> themselves. > > Does anybody know of such a chip that's actually available in the wild? Or > are > we writing drivers for speculative possible chips? > I had troubles with the Silicon Motion SM501/SM502 endianess on PowerPC PCI vs. LocalBus. The chip also has a register to swap endianess, but that seems to only affect some LocalBus modes. The current fb and X drivers are working, but when it comes to font aliasing and hw-acceleration, the problems start to rise again... Regards, Clemens ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel oops while duming user core.
Scott Wood schrieb:
> On Thu, Jan 31, 2008 at 10:15:27AM -0600, Nathan Lynch wrote:
>> Rune Torgersen wrote:
>>> I get the following kernel core while a user program I have is dumping
>>> core.
>>> Any DIeas at what to look for? (this is runnign 2.6.24, arch/powerpc on
>>> a 8280)
>>> When runnign the program on 2.6.18 arch/ppc, the program gets a sig 11
>>> and dumps core.
>>> On 2.6.24, I ghet the kernel oops, and then the program hangs sround
>>> forever and is unkillable.
>> Hmm, this is the second report of 2.6.24 crashing in
>> __flush_dcache_icache during a core dump; see:
>> http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048662.html
>>
>> Is this easily recreatable?
>
> Yes, this program does it reliably:
>
> #include
> #include
> #include
> #include
>
> void *threadfn(void *arg)
> {
> fprintf(stderr, "threadfn\n");
> fflush(stderr);
> sleep(1);
> *(char *)0=0;
> return NULL;
> }
>
> int main(void)
> {
> pthread_t thread[4];
> int i;
>
> for (i = 0; i < 4; i++)
> pthread_create(&thread[0], NULL, threadfn, NULL);
>
> for (;;);
> }
Ack!
This is a MPC8540ADS arch/powerpc compatible environment here:
Feb 2 12:59:17 fox_1 kernel: Unable to handle kernel paging request for data
at address 0x4802f000
Feb 2 12:59:17 fox_1 kernel: Faulting instruction address: 0xc000d5b8
Feb 2 12:59:17 fox_1 kernel: Oops: Kernel access of bad area, sig: 11 [#1]
Feb 2 12:59:17 fox_1 kernel: MPC85xx ADS
Feb 2 12:59:17 fox_1 kernel: Modules linked in:
Feb 2 12:59:17 fox_1 kernel: NIP: c000d5b8 LR: c0010fb8 CTR: 0080
Feb 2 12:59:17 fox_1 kernel: REGS: c24abb20 TRAP: 0300 Not tainted (2.6.24)
Feb 2 12:59:17 fox_1 kernel: MSR: 00029000 CR: 2288 XER:
Feb 2 12:59:17 fox_1 kernel: DEAR: 4802f000, ESR:
Feb 2 12:59:17 fox_1 kernel: TASK = cf894d20[942] 'oops' THREAD: c24aa000
Feb 2 12:59:17 fox_1 kernel: GPR00: c22c7680 c24abbd0 cf894d20 4802f000
0080 000f8b60 4802f000
Feb 2 12:59:17 fox_1 kernel: GPR08: c22c7680 08d1
2288 10018a64 0006 c035a300
Feb 2 12:59:17 fox_1 kernel: GPR16: 00024000 c038 c24aa000 c24abc9c
c24abc98 c2570480 c22c7680 c038
Feb 2 12:59:17 fox_1 kernel: GPR24: c0390420 cf09d000 c0497b60 c5b63948
4802f000 c24aa000 00bc c0497b60
Feb 2 12:59:17 fox_1 kernel: NIP [c000d5b8] __flush_dcache_icache+0x14/0x40
Feb 2 12:59:17 fox_1 kernel: LR [c0010fb8] update_mmu_cache+0x94/0x98
Feb 2 12:59:17 fox_1 kernel: Call Trace:
Feb 2 12:59:17 fox_1 kernel: [c24abbd0] [c24aa000] 0xc24aa000 (unreliable)
Feb 2 12:59:17 fox_1 kernel: [c24abbe0] [c005d978] handle_mm_fault+0x374/0x6a4
Feb 2 12:59:17 fox_1 kernel: [c24abc30] [c005ddd0] get_user_pages+0x128/0x384
Feb 2 12:59:17 fox_1 kernel: [c24abc90] [c00a80d8] elf_core_dump+0xab8/0xb74
Feb 2 12:59:17 fox_1 kernel: [c24abd30] [c007718c] do_coredump+0x730/0x758
Feb 2 12:59:17 fox_1 kernel: [c24abe30] [c002eeb0]
get_signal_to_deliver+0x244/0x3c4
Feb 2 12:59:17 fox_1 kernel: [c24abe80] [c000782c] do_signal+0x48/0x264
Feb 2 12:59:17 fox_1 kernel: [c24abf40] [c000e4ac] do_user_signal+0x74/0xc4
Feb 2 12:59:17 fox_1 kernel: Instruction dump:
Feb 2 12:59:17 fox_1 kernel: 4d820020 7c8903a6 7c001bac 38630020 4200fff8
7c0004ac 4e800020 6000
Feb 2 12:59:17 fox_1 kernel: 54630026 38800080 7c8903a6 7c661b78 <7c00186c>
38630020 4200fff8 7c0004ac
Feb 2 12:59:17 fox_1 kernel: ---[ end trace a1d91e665173315a ]---
Feb 2 12:59:17 fox_1 kernel: note: oops[942] exited with preempt_count 1
It does not oops when the core dump is disabled.
Regards,
Clemens
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: tiny login
pjmaiya schrieb: > hi, - don't cross-post - don't post HTML to the lists > I am using tiny login provided by montavista. Binaries already obtained > from tool provided from montavista. We are able to add only 10 users. > But I need to add more than 10 users. Tried to contact montavista for support? ;-) > I have already downloaded free open source for tinylogin > (tinylogin-1.4). Can we modifiy this source code of this version and > support users more than 10?? > If yes, can somebody inform step to build tiny login and installation > method. Well, you propably want to understand the advantage of open source software first. You can (depending on the license) change the code according to your needs... Read: http://tldp.org/HOWTO/Software-Building-HOWTO.html If you have questions, please tell exactly, where you have a problem. $ wget http://tinylogin.busybox.net/downloads/tinylogin-1.4.tar.bz2 $ tar xvf tinylogin-1.4.tar.bz2 $ cd tinylogin-1.4 $ make works like a charm. A quick look into login.c says: // login defines #define TIMEOUT 60 #define FAIL_DELAY3 #define EMPTY_USERNAME_COUNT10 ... which looks quite promising! Ask the busybox guys for details since this is off-topic here. Regards, Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC85xx DMA drivers, first testing results.
Hi There!
I just tried to use the fsldma on the mpc8540. It seems to work fine
here, but I would be glad if somebody can confirm before I move on:
I added the following to my mpc8540ads compatible board's .dts
(see my comments, where the not yet available documentation
was unclear):
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc8540-dma", "fsl,eloplus-dma";
device-id = <0>;
reg = <21300 4>;/* DGSR - DMA general status register */
/* reg = <21000 4>;*/ /* or use offset of DMA machine ??? */
ranges = <0 21100 200>; /* we have 4 DMA channels at 21100, size=80
each */
[EMAIL PROTECTED] {
compatible = "fsl,mpc8540-dma-channel",
"fsl,eloplus-dma-channel";
device-id = <0>; /* or cell-index ??? */
reg = <0 80>;
interrupt-parent = <&mpic>;
interrupts = <14 2>;
};
[EMAIL PROTECTED] {/* or use 0,1,2,3 instead of 0,80,100,180
??? */
compatible = "fsl,mpc8540-dma-channel",
"fsl,eloplus-dma-channel";
device-id = <1>;
reg = <80 80>;
interrupt-parent = <&mpic>;
interrupts = <15 2>;
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8540-dma-channel",
"fsl,eloplus-dma-channel";
device-id = <2>;
reg = <100 80>;
interrupt-parent = <&mpic>;
interrupts = <16 2>;
};
[EMAIL PROTECTED] {
compatible = "fsl,mpc8540-dma-channel",
"fsl,eloplus-dma-channel";
device-id = <3>;
reg = <180 80>;
interrupt-parent = <&mpic>;
interrupts = <17 2>;
};
};
$ dmesg then says:
of-fsl-dma e0021300.dma: Probe the Freescale DMA driver for fsl,mpc8540-dma
controller at 0xe0021300...
of-fsl-dma-channel e0021100.dma-channe: selftest: start...
of-fsl-dma-channel e0021100.dma-channe: selftest: finished, err=0.
of-fsl-dma-channel e0021100.dma-channe: #0 (fsl,mpc8540-dma-channel), irq 21
of-fsl-dma-channel e0021180.dma-channe: selftest: start...
of-fsl-dma-channel e0021180.dma-channe: selftest: finished, err=0.
of-fsl-dma-channel e0021180.dma-channe: #1 (fsl,mpc8540-dma-channel), irq 22
of-fsl-dma-channel e0021200.dma-channe: selftest: start...
of-fsl-dma-channel e0021200.dma-channe: selftest: finished, err=0.
of-fsl-dma-channel e0021200.dma-channe: #2 (fsl,mpc8540-dma-channel), irq 23
of-fsl-dma-channel e0021280.dma-channe: selftest: start...
of-fsl-dma-channel e0021280.dma-channe: selftest: finished, err=0.
of-fsl-dma-channel e0021280.dma-channe: #3 (fsl,mpc8540-dma-channel), irq 24
I added another dev_info() to get at least a glue that the selftest is run.
It looks like dev_info(fsl_chan->dev, ...); seems to be truncated.
I have no idea if interrupts are working well... the callback isn't
used yet.
Otherwise, nice work! :-) I'm looking forward to see this functionality
in mainline.
Regards,
--
Clemens Koller
__
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Straße 45/1
Linhof Werksgelände
D-81379 München
Tel.089-741518-50
Fax 089-741518-19
http://www.anagramm-technology.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Are the MPC85xx DMA drivers already in a tree?
Clemens Koller schrieb: > I want to update a driver to test my mileage with the > Freescale DMA drivers for MPC85xx from Zhang Wei from 2007-09-07. > > Are those already available in some git tree to pull from? > What are the most current trees for powerpc development? > (galak, paulus, ?) Okay, I've found that stuff in 2.6.24-rc4-mm1 I'll see if I can get something to work. Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Are the MPC85xx DMA drivers already in a tree?
Hi! I want to update a driver to test my mileage with the Freescale DMA drivers for MPC85xx from Zhang Wei from 2007-09-07. Are those already available in some git tree to pull from? What are the most current trees for powerpc development? (galak, paulus, ?) Also, any Documentation to the current/planned DMA implementation or demo drivers are welcome. I want to pull big chunks of bulk data from an FPGA connected to the local bus to main memory. Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PCI to Parallel for PowerPC
Bai Shuwei schrieb: Please don't cross-post. > hi, all > I bought a SMC1500 stepper motor card. And it can connect with host > through parallel port. My target board is PowerPC 440, which hasn't > parrallel port. So I bought a PCI to Parallel line for SMC1500. But when > I run the stepper motor, I find it's not stable. I doubt there are > somthing wrong with my PCI to Parallel line. So I beg somebody can tell > me where I can bought the appropriate conversion line from PCI to > parallel, and does somebody give me some idea about how to control my > stepper motor through PowerPC 440? thx all Put that PCI Card to your host where your stepper was working properly to see if it's a hardware issue with that card. Then it depends on how you control your stepper motor. If you use some bit-banging (which I wouldn't recommend) to drive each winding and want to have smooth movement, you need a very precise timing when it comes to some "more than low-speed" stepper motors, otherwise your motors will start to coggle. To be precise: you will first have to figure out what leads to the effect of "it's not stable". Do you have an Oscilloscope? Regards, -- Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm-technology.com Phone: +49-89-741518-50 Fax: +49-89-741518-19 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Help required for porting ISP1362 usb device driver
Hello, Vikram! Vikram Kone schrieb: > Hi.. > I'm a linux newbie and im working on porting the USB driver ISP1362 by > Philips on to my Freescale ppc board. Please don't crosspost. Please don't write HTML. > I dont know how to do this... so if any of you can tell me how to do > this step by step, i would be very grateful to you > > Few details.. > I'm running RHEL with kernel 2.4.21 on a PC (i386 machine) > Target Machine is MPC8548 CDS by Free scale (ppc architecture) running > kernel version 2.6.11 Did you try something like: http://www.freescale.com/files/32bit/doc/app_note/AN3094.pdf?fsrch=1 I think it's one of these "step by step" things. (You should consider moving up to the latest Kernel which is 2.6.22.1 as of today. Nobody fixes bugs on that old kernel.) > I do have a ppc tool chain, if that helps. What tool chain? > but i dont know how to use it Did you read the documentation? What problem do you have? > P.S. I downloaded the deive driver and host controller drivers from > sourceforge.net and both of them seem to work for 2.6.6 kernel for i386 > arch .. Fine! > P.P.S : Wolfgang ??!1 Can you help me out... I went through the archives > on the list and seems thatu answered many Qs on this driver. But i didnt > find any post specifcally for my problem..so Sorry, my crystal ball is broken. You didn't tell us any details about your problem. > This e-mail may contain confidential and privileged material for the > sole use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply e-mail and delete all copies of this message. Oops... If I am not the intended recipient, please: > /dev/null my mail. Regards, -- Clemens Koller __ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
