Messages in this thread | | | Date | Tue, 3 May 2016 18:01:39 +0530 | From | Laxman Dewangan <> | Subject | Re: [PATCH 3/6] soc/tegra: pmc: Add support for IO pads power state and voltage |
| |
On Tuesday 03 May 2016 06:04 PM, Jon Hunter wrote: > On 02/05/16 13:17, Laxman Dewangan wrote: >> + >> + return tegra_io_rail_power_on(dpd_bit); > From a readability standpoint the above seems weird because > tegra_io_pads_power_enable() takes an ID as the argument, translates it > to a bit value and passes it to tegra_io_rail_power_on() which also > takes an ID for the argument.
Yaah, I did not want to duplicate the implementation and hence it is there. We will get rid of the older APIs once this is IN and new mechanism there.
>> + >> + bval = (io_volt_uv == 3300000) ? BIT(pwr_bit) : 0; >> + >> + mutex_lock(&pmc->powergates_lock); >> + tegra_pmc_read_modify_write(PMC_PWR_DET, BIT(pwr_bit), BIT(pwr_bit)); >> + tegra_pmc_read_modify_write(PMC_PWR_DET_VAL, BIT(pwr_bit), bval); >> + mutex_unlock(&pmc->powergates_lock); > There are 4 instances of BIT(pwr_bit). May be we should do this once or > have tegra_io_pads_to_power_val() return the bit?
OK, will re-write this part.
> >> +int tegra_io_pads_power_disable(int io_pad_id); >> +int tegra_io_pads_power_is_enabled(int io_pad_id); > What I don't like here, is now we have two public APIs to do the same > job because tegra_io_pads_power_enable/disable() calls > tegra_io_rail_power_off/on() internally. Furthermore, the two APIs use > different ID definitions to accomplish the same job. This shouldn't be > necessary.
Currently SOR driver is using the tegra_io_rail_power_off/on() APIs. Once the proper interface available then I will move sor driver to use new method and then we can full get rid of older APIs and macros.
Till that, we need to have this.
>
| |