Re: [PATCH 2.6.29-rc1-git4] mfd: da9030 usb charge pump support within mfd driver.

[Eric Miao]

On Thu, Jan 15, 2009 at 3:28 PM, Mike Rapoport <mike@xxxxxxxxxxxxxx> wrote:
>
>
> Eric Miao wrote:
>> On Thu, Jan 15, 2009 at 2:34 PM, Mike Rapoport <mike@xxxxxxxxxxxxxx> wrote:
>>>
>>> Eric Miao wrote:
>>>> On Thu, Jan 15, 2009 at 2:16 AM, Jonathan Cameron <jic23@xxxxxxxxx> wrote:
>>>>> From: Jonathan Cameron <jic23@xxxxxxxxx>
>>>>>
>>>>> Add support for changing the mode of the da9030 usb charge pump
>>>>>
>>>> Well, if it is totally USB charger related, I'd suggest to move this into
>>>> the dedicated driver. This mfd/da903x.c serves as a common code
>>>> base for all sub-peripherals.
>>> It's not exactly related to the charger, it's rather related to the USB voltage
>>> supplied to USB devices attached to PXA OHCI.
>>> Indeed the mfd/da903x.c serves as a common core for sub-peripherals, but IMHO
>>> adding a subdevice driver because of single method doesn't worth the overhead.
>>> I'm for the solution Jonathan proposes.
>>>
>>
>> Mmm... then who will be the invoker? I'm a bit upset about this
>> being exported while called out of control. If it works as the
>> name suggested, setting some mode, maybe we can have a
>> platform data field specifying this, and hide this totally within
>> the driver. I didn't look into this too much, just a concern here.
>
> The USB charge pump should be enabled if DA9030 should supply USB VBUS for USB
> devices connected to PXA OHCI port. In the most simple case, when the USB port
> is configured to be host only the platform data can be used to setup the charge
> pump once and forget about it. However, if the USB port is configured as OTG,
> the charge pump should be toggled depending on OTG ID.
> In EM-X270 I have a GPIO connected to OTG ID pin of the connector and according
> to the GPIO state I toggle the da9030 USB charge pump.
>

OK, now I understand the problem. The optimal way would be to invent
an abstraction for this external charge pump (in terms of PXA27x OTG
controller) and make DA9030 a derived class of it. But the PXA27x OTG
solution is really a hybrid one, and the existing OTG code is in a mess
(without a clear abstraction), the sub-optimal way would let platform code
do this trick. Yet the platform code is currently suffering from a missed
API to retreive this dynamically scanned I2C device. Mmm...stumped.

I would expect the final solution to be clean enough, that requires some
dependent stuffs to be modified, and the final look of this patch may be a
bit different.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/