[parisc-linux] B2k and CONFIG_PDC_CONSOLE pb: followup

[Joel Soete]

>yup - that's fixed in 2.6 slightly better.
>Look for pdc_io_reset_devices() in drivers/parisc/sba_iommu.c.
>You can backport and test that change to 2.4, I'd be happy to apply it.

Well, here is attached 95% of work (see attached text file PDC_WRK.diff)
Please double check (may be still removing temporarely useless EXPORT_SYMBOL
and finalyse chg of 'direction' type to an enum?)

But it doesn't help it just move the pb when setup SBA :(
[snip]
5. Memory (1) at 0xfed10200 [49], versions 0x
d, 0x0, 0x9
CPU(s): 1 x PA8600 (PCX-W+) at 400.000000 MHz
SBA found Astro 2.1 at 0xfed00000

>The problem is if suckyio USB (or any device) is still doing DMA when
>we reprogram the IOMMU, it will cause an HPMC.

hmm I didn't get any hmpc but it more act as if it was sending something
to write to the cdrom (iether the cdrom was connected or not) or trying to
reset with wrong info?

> The reason is we are fundementally changing how DMA works (non-coherent
> to coherent) and PDC doesn't reprogram the suckyIo USB accordingly.
> C3000 (and related systems) provides a special PDC call to disable USB.
> "ccio" (eg C200) systems can have the same problem with LAN boot.
Even in 2.6 I got exactly the same pb with this ?*# b2k (and unforunately
I have only one b2k to test :(, just in case it was a pb on this machine?)

>> I also try to bypass this memcpy (and restore pdc_suspend_usb() call)
>> and it boot also well.

The same with patch.

>I think you've just prevented either PDC or Linux from using a PDC device.
Ok


>> In sumary, on the b2k, this early memcpy() seems to break something in
>> the later pdc_suspend_usb() call.

>It's the other way around. pdc_suspend_usb() is breaking PDC_CONSOLE.
>See email related to linux-2.6 c3000 serial console problems late
>last year.

Still have to read back again (sorry)

>AFAIK, the memcpy just enables the PDC to use a serial console.
>But pdc_suspend_usb() apperently blows away the whole suckyio chip
>and thus PDC can no longer use suckyio serial either. Hrmm..I t
ought
>there was a IO_RESET_AND_CLEAR pdc call in that same chunk of code.

Sorry I didn't find any IO_RESET_AND_CLEAR :(

Even though, I try to call pdc_io_reset(); just before pdc_io_reset_device();.
But it doesn't help ;)


>Anyway, Figuring out some additional info could help:
>   (a) know which devices migh have DMA enabled when the OS gets control

How may do this ?)

>   (b) disable just the DMA
>   (c) detect when PDC_CONSOLE wants to use a device whose DMA we've disabled

I would also like to be sure that the same info are used (and btw send to
pdc) by real32_call_asm and so just put some printk before this call real32_call_asm();
but it seems to create an infinite loop of print. Any idea?

Where should I found more info on all of this 'cmd' send to pdc?

Thanks in advance for additional attention,
    Joel




-------------------------------------------------------------------------
Tiscali ADSL: 12 mois à 29,50 €/mois! L'Internet rapide, c'est pour tout
le monde.
http://reg.tiscali.be/default.asp?lg=fr


-------------- next part --------------
A non-text attachment was scrubbed...
Name: PDC_WRK.diff
Type: application/octet-stream
Size: 22581 bytes
Desc: not available
Url : http://lists.parisc-linux.org/pipermail/parisc-linux/attachments/20040122/967143a1/PDC_WRK-0001.obj