Hi,
> Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
>
> Hi,
>
> On Thursday 06 March 2014 02:49 PM, Anton Tikhomirov wrote:
> > Hi,
> >
> >> Subject: RE: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
> >>
> >> Hi,
> >>
> >>> Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY driver
> >>>
> >>> Hi,
> >>>
> >>> On Thursday 06 March 2014 02:22 PM, Anton Tikhomirov wrote:
> >>>> Hello,
> >>>>
> >>>>> Subject: Re: [PATCH v9 3/4] phy: Add new Exynos USB 2.0 PHY
> driver
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Thursday 06 March 2014 01:56 PM, Anton Tikhomirov wrote:
> >>>>>> Hi Kamil,
> >>>>>>
> >>>>>> ...
> >>>>>>
> >>>>>>> +| 3. Supporting SoCs
> >>>>>>> ++--------------------
> >>>>>>> +
> >>>>>>> +To support a new SoC a new file should be added to the
> >>> drivers/phy
> >>>>>>> +directory. Each SoC's configuration is stored in an instance
> of
> >>> the
> >>>>>>> +struct samsung_usb2_phy_config.
> >>>>>>> +
> >>>>>>> +struct samsung_usb2_phy_config {
> >>>>>>> + const struct samsung_usb2_common_phy *phys;
> >>>>>>> + unsigned int num_phys;
> >>>>>>> + bool has_mode_switch;
> >>>>>>
> >>>>>> You missed rate_to_clk here.
> >>>>>>
> >>>>>>> +};
> >>>>>>> +
> >>>>>>
> >>>>>> ...
> >>>>>>
> >>>>>>> diff --git a/drivers/phy/phy-samsung-usb2.c b/drivers/phy/phy-
> >>>>> samsung-
> >>>>>>> usb2.c
> >>>>>>> new file mode 100644
> >>>>>>> index 0000000..c3b7719
> >>>>>>> --- /dev/null
> >>>>>>> +++ b/drivers/phy/phy-samsung-usb2.c
> >>>>>>> @@ -0,0 +1,222 @@
> >>>>>>> +/*
> >>>>>>> + * Samsung SoC USB 1.1/2.0 PHY driver
> >>>>>>> + *
> >>>>>>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> >>>>>>> + * Author: Kamil Debski <k.debski@xxxxxxxxxxx>
> >>>>>>> + *
> >>>>>>> + * This program is free software; you can redistribute it
> >> and/or
> >>>>>>> modify
> >>>>>>> + * it under the terms of the GNU General Public License
> version
> >> 2
> >>>>> as
> >>>>>>> + * published by the Free Software Foundation.
> >>>>>>> + */
> >>>>>>> +
> >>>>>>> +#include <linux/clk.h>
> >>>>>>> +#include <linux/mfd/syscon.h>
> >>>>>>> +#include <linux/module.h>
> >>>>>>> +#include <linux/of.h>
> >>>>>>> +#include <linux/of_address.h>
> >>>>>>> +#include <linux/phy/phy.h>
> >>>>>>> +#include <linux/platform_device.h>
> >>>>>>> +#include <linux/spinlock.h>
> >>>>>>> +#include "phy-samsung-usb2.h"
> >>>>>>> +
> >>>>>>> +static int samsung_usb2_phy_power_on(struct phy *phy)
> >>>>>>> +{
> >>>>>>> + struct samsung_usb2_phy_instance *inst =
> >>> phy_get_drvdata(phy);
> >>>>>>> + struct samsung_usb2_phy_driver *drv = inst->drv;
> >>>>>>> + int ret;
> >>>>>>> +
> >>>>>>> + dev_dbg(drv->dev, "Request to power_on \"%s\" usb phy\n",
> >>>>>>> + inst->cfg->label);
> >>>>>>> + ret = clk_prepare_enable(drv->clk);
> >>>>>>
> >>>>>> clk_prepare_enable() can sleep, and therefore doesn't allow
> >>>>>> samusng_usb2_phy_power_on() to be used in atomic context
> >>>>>> (e.g. inside spin_lock-ed area), what sometimes may be desirable.
> >>>>>> What about to prepare clock in probe, and just enable it here
> >>>>>> (note: clk_enable() doesn't sleep).
> >>>>>
> >>>>> The PHY power-on callback is anyway called with mutex held, so I
> >>> guess
> >>>>> it's fine to have clk_prepare_enable() here.
> >>>>
> >>>> If we rely totally on generic PHY functions such as phy_power_on()
> >>>> and friends, why do we need to use locking in callbacks at all.
> >>>
> >>> Didn't get you.. We don't want to invoke power_on when init is
> >> getting
> >>> executed or you don't want power on or power off to get executed
> >>> simultaneously right? So we need to protect it.
> >>
> >> I mean callbacks such as samsung_usb2_phy_power_on() which uses
> >> spin_lock.
> >> It's already protected by mutex in phy_power_on().
> >
> > Well... phy_power_on() uses mutex to protect power_on() callback.
> > power_on() is samsung_usb2_phy_power_on() in our case.
> > samsung_usb2_phy_power_on() uses spinlock.
> > My question is why do we need to use spinlock _inside_ callback
> > if it is already protected by mutex.
>
> It is needed when the same PHY provider implements multiple PHYs.
> phy-core can protect phy-ops of same PHY. However if the PHY provider
> implements multiple PHYs, phy-core won't be able to protect.
Thank you Kishon. Now it's clear.
--
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
