Chen Peter-B29397 <B29397@xxxxxxxxxxxxx> writes:
>
>> >
>> > - How to support OTG, you will give up struct usb_otg or not?
>>
>> I'm not sure what you mean by giving up usb_otg. What we were discussing
>> with Heikki and Felipe is reworking the otg framework so that, for
>> example, we have a common otg state machine instead of reimplementing it
>> in every otg driver. We planned for this work to be based upon this
>> chipidea driver. Maybe this topic should be brought up again.
>>
> As I haven't seen otg_set_host at your host driver, and no otg_set_vbus
> when device <--> host switch.
Ah, no, it wasn't my intention to avoid using usb_otg for otg, I just
really didn't want to implement a full otg driver yet, because it's a
big task on its own.
>
>> In any case, my plan is that the otg part of ci_hdrc should be based on
>> those otg framework changes, which should come first. Heikki, do you
>> have anything to add?
>>
> OK, understand. Currently, I just want to know that ID switch can work
> or not at your board?
Currently, I have our charger chip take care of the vbus switching. It's
configured to follow the id pin state.
> By the way, why not return directly when it sees a id change interrupt
> at ci_irq?
Technically, OTGSC is independent from host or device mode, so I assume
there is a possibility of other device or host related interrupts
arriving at the same time.
>> > - When ID switch occurs, do udc_start/udc_stop is enough, seems no
>> registers
>> > operation?
>>
>> The ID switch will cause the stop() for current role and the start() for
>> the new role, which at the very least resets the device and sets
>> USBMODE_CM_{D,H}C. Also, when the gadget is stopped, UDC is
>> deinitialized and queue heads are flushed. Does this answer your
>> question?
>>
> I don't know if you have used any otg drivers at your board when using your patchset.
> When host switches device, the host->stop will not call controller reset,
> and udc_start only calls otg_set_peripheral, I don't know where you set device
> mode at udc_start.
I do call hw_device_reset(..., USBMODE_CM_DC) in udc_start *unless* the
SHARED flag is set by the platform (currently, msm does that). The
SHARED flag basically means that we have other driver(s) taking care of
some of the functionality, like controller reset. In case of msm it's
done by msm_otg.c. If we expand ci_hdrc to handle otg properly, there
won't be a need for that (and the separate otg and ehci drivers).
>> > - I have not found vbus interrupt code which is used to stand for
>> > connect and disconnect at device mode.
>>
>> It's not there yet. I think it should be in the otg part of the
>> driver. What do you think?
> Yes, again, no vbus on/off, does your id switch is ok? Your vbus is always
> on?
Like I say above, it's taken care of by the charger on our board, so it
wasn't my priority to sort out driving vbus. That's another thing to do
in the next releases.
>> > - Current, there is no PHY Layer code (I will begin to do it soon),
>> > so your PHY operation is at udc code, once the PHY Layer code is ready,
>> > do you will move it to core.c?
>>
>> I think of phy code as platform code, it doesn't directly concern the
>> chipidea driver, except for the bits where chipidea might need explicit
>> configuration of the phy type. But I think that is still separate from
>> the actual phy code. My understanding is, usb controllers should be
>> really decoupled from phy code and shoud only talk to one another
>> through certain api. Again, Heikki might have more to say on this.
> Yes, it should talk with PHY's API, when init, wakeup, suspend are
> needed.
>
>
>>
>> > Seems you have moved msm udc to chipidea folder, but have not changed
>> > host and otg part, how msm user goes on using usb driver?
>>
>> Well, both ehci-msm.c and msm-otg.c are separate drivers, and nothing
>> has changed from their prospective. With my patchset, they should still
>> work as they did before it.
>>
> Oh, I did not mention CONFIG_USB_CHIPIDEA_HOST can be not defined.
> Have you tried to not define CONFIG_USB_CHIPIDEA_HOST at your board?
Yes, it works fine with CONFIG_USB_CHIPIDEA_HOST disabled. No role
switching, obviously. :)
Regards,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
