Hi Rahul,
On 04/09/2014 11:12 AM, Rahul Sharma wrote:
> Hi Tomasz,
>
> On 9 April 2014 14:07, Andrzej Hajda <a.hajda@xxxxxxxxxxx> wrote:
>> Hi Tomasz,
>>
>> On 04/08/2014 04:37 PM, Tomasz Stanislawski wrote:
>>> Add exynos-simple-phy driver to support a single register
>>> PHY interfaces present on Exynos4 SoC.
>>>
>>> Signed-off-by: Tomasz Stanislawski <t.stanislaws@xxxxxxxxxxx>
[snip]
>>> +
>>> + regs = devm_ioremap(dev, res->start, res->end - res->start);
>>> + if (!regs) {
>>> + dev_err(dev, "failed to ioremap registers\n");
>>> + return -EFAULT;
>>> + }
>>
>> Why not devm_ioremap_resource? If not, resource_size function calculates
>> length of resource correctly.
>>
>> Anyway I like the idea of implementing multiple phys in one driver.
>> The only drawback I see is that some phys will be created even there are
>> no consumers for them. To avoid such situation you can try to use
>> lazy approach - create phy only if there is request for it,
>> exynos_phy_xlate callback should allow this.
>>
>> Regards
>> Andrzej
>>
>
> Idea looks good. How about keeping compatible which is independent
> of SoC, something like "samsung,exynos-simple-phy" and provide Reg
> and Bit through phy provider node. This way we can avoid SoC specific
> hardcoding in phy driver and don't need to look into dt bindings for
> each new SoC.
A very nice idea BUT there is a very strong pressure from DT guys
to avoid adding any bit fields/offsets/masks in DT nodes.
Hopefully, as long as driver name starts with "exynos-" prefix
one can hide SoCs specific tricks deep inside driver code.
The idea behind this driver was not to create a generic phy for 1-bit
devices but rather to hide SoC-specific issues from client drivers
like DRM-HDMI.
>
> We can use syscon interface to access PMU bits like USB phy.
> PMU is already registered as system controller
>
Ok. I will try to use it in PATCHv3.
> Regards,
> Rahul Sharma.
>
Regards,
Tomasz Stanislawski
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
