Re: Two remain problems at chipidea driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Peter Chen <peter.chen@xxxxxxxxxxxxx> writes:

> Hi Alex and all,
>
> Currently, we have two problems to block chipidea driver coming
> development.
>
> As there are so many chipidea versions, we impossible to collect
> all to make a decision, it is better to cover most of the cases,
> and using device tree (or platform data) to cover exceptions
> if they exist.
>
> 1. USB Mode Problem
> How can we decide USB mode (gadget, host and otg) at driver, and
> how to read OTGSC register? Below is my pinion.
>
> - We get gadget or host support from CAP_DCCPARAMS(DCCPARAMS_DC or DCCPARAMS_HC),
> If both DCCPARAMS_DC and DCCPARAMS_HC are 1, then the mode is "otg".
> If DCCPARAMS_DC = 1 and DCCPARAMS_HC = 0, the mode is "gadget".
> If DCCPARAMS_DC = 0 and DCCPARAMS_HC = 1, the mode is "host".
> If DCCPARAMS_DC = 0 and DCCPARAMS_HC = 0, prompt an error 
> and try to get it from DT.
>
> - Override the value using DT, please do not consider too much between
> dule_role and otg. We just consider all controllers which supports host
> and gadget at the same time as otg device. The exception may not be existed
> or be too long to use.

The mips platform support patchset that Svetoslav is doing is for such a
device. In any case, I see no reason to not support all the possible
devices.

> - For how to read OTGSC register, we need another flag to indicate
> it is otg capable (DCCPARAMS_DC = 1 and DCCPARAMS_HC = 1), if it is
> otg capable, read OTGSC is allowed. Here, OTG capable device can work
> as gadget only mode.

I'd say, in the core driver:
  1) get dr_mode from platform data
  2) only if that's DR_MODE_UNKNOWN (iirc), read DCCPARAMS, since it's
  not guaranteed to work across all chipideas;
  3) if dr_mode == OTG or dr_mode == UNKNOWN and DCCPARAMS has both DC
  and HC, set ci->otg, which determines if we can access otgsc
  4) if dr_mode == DUAL_ROLE, don't set ci->otg.

Do you see any problems with this?

> 2. Chipidea Core Driver DT Support
> I agree we move some core things, like vbus, operation_mode, phy to core
> driver using DT. But for clock, it is better still exist at glue
> layer, clock is input for chipidea core, chipidea core doesn't need
> to know its clock from IC point. Like clock, the wakeup setting, low
> power sequence are platform specific, they are designed by individual
> companies.

Hmm, if the clock is external to chipidea, I guess it should be ok to
keep it in the platform code as long as it is entirely contained in the
platform code, that is, no awkward passing *clk pointers to the core and
back.

> Let me know your opinion about these two problems and your plan for them.
> Thanks.

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux