Hi,
Olav Kongas writes:
> > Michael Moedt writes:
> > > Hello yet again.
> > > I have a question about the ohci-isp1362 driver.
> > >
> > > Do you know where the dev->addr_reg and dev->data_reg are set?
> > > They look like virtual addresses, but what addresses are they
> > > ioremapped to? (Which file and where-abouts can I find this? I'm
> > > having trouble finding it)
> > >
> > They are set from resources in the platform_device:
> > You can either specify two IORESOURCE_MEM resources that define the
> > phyiscal address of the ISP address port and the data port
> > respectively or define one resource with '.start' pointing to the
> > address port and '.end - sizeof(u16)' pointing to the data port.
>
> Lothar, from your resource structure I can see that the A0
> pin of your 1362 is connected to MA2 (A2 of address bus),
> right? If it is connected to MA1 (as it is on our board)
> then one gets a continuous register space for these two
> ports. Wouldn't it be more natural to define them in a
> single resource entry like that:
>
The driver supports both variants as I had described above. If only 1
memory resource is found, data_reg and addr_reg are set up to be at
the start and the end of the mapped region.
When two descriptors are present, the first maps the data
register and the second one the address register (see note below).
> static struct resource ohci_isp1362_resources[] = {
> {
> .name = "mem",
> .start = PHYS_USB_BASE,
> .end = PHYS_USB_BASE + 4,
> .flags = IORESOURCE_MEM,
> },
>
> This would mean that the order of reg_addr and reg_data
> initialization in ohci_hcd_isp1362_drv_probe() should be
> exchanged. Also, every platform-specific resource should be
> fixed to accommodate this. This may be inconvenient as there
> are already some people implemented their resources
> according to the current scheme. If you agree to change
> this, I can send the patch. Just tell.
>
Ooops. I already had noticed this and done this reversal, but it
somehow didn't make it into the finally released code ;(
(The SL811 from which I derived this code has the registers reversed)
I'll put a revised version of the code on our web page soon, which
will include this fix.
> Also a question: at the very end of hc_isp1362_chip_probe(),
> isp1362_set_hw_reset(dev) is called. For me this call
> results in failure of the initialization of my 1160 due to
> asserted hw-reset pin. Hardware reset preformed above in
> the same function occurs correctly. Must this call really be
> there for 1362?
>
hw_reset is deasserted in isp1362_start_chip() before the chip is
accessed. So it should not matter that the reset is asserted again
in hc_isp1362_chip_probe() after finding the chip.
Lothar Wassmann
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
