[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48730DE2.2050302@gmail.com>
Date: Tue, 08 Jul 2008 14:49:06 +0800
From: Eric Miao <eric.y.miao@...il.com>
To: Stefan Schmidt <stefan@...enfreihafen.org>
CC: pHilipp Zabel <philipp.zabel@...il.com>,
linux-arm-kernel@...ts.arm.linux.org.uk, sameo@...nedhand.com,
linux-kernel@...r.kernel.org, Daniel Ribeiro <wyrm@...nezx.org>
Subject: Re: [Patch 06/10] mfd: PCAP driver for the Motorola EZX GSM mobile
phones
Stefan Schmidt wrote:
>> Otherwise I'd dislike the hardcoded IRQ numbers in the MFD driver.
>
> So far it seems to be no problem. If there is a strong feeling to change this we
> will of course work on that. Personally I would prefer to do this when new users
> of this driver appear.
The irq2pcap[] array looks horrible to me. It's actually a sparse array.
Isn't there a nice 1:1 mapping using a formular??
Besides, the IRQ numbering scheme has now changed to a more generic way,
I suggest to pull from Russell's latest git tree and rebase the IRQ
part.
>
>> The machine_is_xyz() calls inside ezx-pcap could be replaced with
>> configuration via platform_data (have pcap_platform_data->cs_inverted,
>> for example)
>
> We had this before and it turned out as messy as this solution. We have one
> machine file that supports up to 6 devices right now. So we would have to deal
> with the same machine_is_xyz macros in the machine file.
>
> We thought it would be better to let the driver handle this. Open for discussion
> of course.
The following block of code:
+ if (pcap_data->cs >= 0) {
+ if (machine_is_ezx_a780() || machine_is_ezx_e680())
+ gpio_direction_output(pcap_data->cs, 1);
+ else
+ gpio_direction_output(pcap_data->cs, 0);
+ }
has 3 occurrences in the driver (2 in ezx_ssp_pcap_putget, 1 in ezx_pcap_probe)
which is good reason to fold this into the platform data.
Well, if the above is done in platform data, I guess you won't mind another bit
flag (e.g. PCAP_REDIRECT_IRQ or something alike) added in platform data, either
>
>>> +#if 0
>>> +#define DEBUGP(x, args...) printk(x, ## args)
>>> +#else
>>> +#define DEBUGP(x, args...)
>>> +#endif
>> Could you remove the custom debug macros and use pr_debug (or even
>> better, dev_dbg) instead?
>
> Will do.
>
>>> +static void __exit ezx_pcap_exit(void)
>>> +{
>>> + return platform_driver_unregister(&ezxpcap_driver);
>>> +}
>>> +
>>> +module_init(ezx_pcap_init);
>> Depending on what platform_devices depend on this, maybe use
>> subsys_initcall here.
>
> Ok, I'll need to look up on this to see if it is an option.
>
>>> +module_exit(ezx_pcap_exit);
>> Why bother with module_exit when the Kconfig option is bool?
>
> Well, matter of taste. :)
>
> Taking care about cleanup is good style. Still you are right that it is useles
> for the time being.
>
>>> +#define PCAP_IRQ_USB4V (1 << 6) /* USB above 4volt???
>>> + called "USBDET_4V" in blob */
>> I assume that's for OTG operation. The VBUS voltage is valid from 4.4 V, and the
>> PXA27x UDC controller has "Vbus valid 4.0 V" and "Vbus valid 4.4 V" interrupts
>
> ok
>
>>> + /* set core voltage */
>>> + ezx_pcap_set_sw(SW1, SW_VOLTAGE, SW_VOLTAGE_1250);
>> Btw, did you see the voltage regulator framework that is in linux-next?
>
> Heard of it, but not read the code yet. It's on my list. I just a bit hesitant
> to base on code that is not in mainline yet. But -next should be ok.
>
>>> -
>>> + platform_device_register(&ezx_pcap_device);
>>> platform_add_devices(devices, ARRAY_SIZE(devices));
>> You could put ezx_pcap_device into the beginning of devices[].
>
> Duh, will fix.
>
> I send out an updated patch tomorrow. Need some sleep now.
>
> Thanks for the feedback.
>
> regards
> Stefan Schmidt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists