From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Kishon Vijay Abraham I <kishon@ti.com>,
robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
grant.likely@linaro.org, devicetree@vger.kernel.org
Cc: rdunlap@infradead.org, linux-doc@vger.kernel.org,
linux-sh@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v5] phy: Renesas R-Car Gen2 PHY driver
Date: Fri, 05 Sep 2014 18:46:29 +0000 [thread overview]
Message-ID: <540A0505.5060008@cogentembedded.com> (raw)
In-Reply-To: <53F4B3E7.3030700@ti.com>
Hello.
On 08/20/2014 06:42 PM, Kishon Vijay Abraham I wrote:
Sorry for the delayed reply, I was busy in other kernel areas. Should have
replied yesterday though...
[...]
>> Index: linux-phy/drivers/phy/phy-rcar-gen2.c
>> =================================>> --- /dev/null
>> +++ linux-phy/drivers/phy/phy-rcar-gen2.c
>> @@ -0,0 +1,341 @@
>> +/*
>> + * Renesas R-Car Gen2 PHY driver
>> + *
>> + * Copyright (C) 2014 Renesas Solutions Corp.
>> + * Copyright (C) 2014 Cogent Embedded, Inc.
>> + *
>> + * 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/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/spinlock.h>
>> +
>> +#include <asm/cmpxchg.h>
>> +
>> +#define USBHS_LPSTS 0x02
>> +#define USBHS_UGCTRL 0x80
>> +#define USBHS_UGCTRL2 0x84
>> +#define USBHS_UGSTS 0x88 /* The manuals have 0x90 */
>> +
>> +/* Low Power Status register (LPSTS) */
>> +#define USBHS_LPSTS_SUSPM 0x4000
>> +
>> +/* USB General control register (UGCTRL) */
>> +#define USBHS_UGCTRL_CONNECT 0x00000004
>> +#define USBHS_UGCTRL_PLLRESET 0x00000001
>> +
>> +/* USB General control register 2 (UGCTRL2) */
>> +#define USBHS_UGCTRL2_USB2SEL 0x80000000
>> +#define USBHS_UGCTRL2_USB2SEL_PCI 0x00000000
>> +#define USBHS_UGCTRL2_USB2SEL_USB30 0x80000000
>> +#define USBHS_UGCTRL2_USB0SEL 0x00000030
>> +#define USBHS_UGCTRL2_USB0SEL_PCI 0x00000010
>> +#define USBHS_UGCTRL2_USB0SEL_HS_USB 0x00000030
>> +
>> +/* USB General status register (UGSTS) */
>> +#define USBHS_UGSTS_LOCK 0x00000300 /* The manuals have 0x3 */
>> +
>> +#define PHYS_PER_CHANNEL 2
>> +
>> +struct rcar_gen2_phy {
>> + struct phy *phy;
>> + struct rcar_gen2_channel *channel;
>> + int number;
>> + u32 select_value;
>> +};
>> +
>> +struct rcar_gen2_channel {
>> + struct device_node *of_node;
>> + struct rcar_gen2_phy_driver *drv;
>> + struct rcar_gen2_phy phys[PHYS_PER_CHANNEL];
>> + int selected_phy;
>> + u32 select_mask;
>> +};
>> +
>> +struct rcar_gen2_phy_driver {
>> + void __iomem *base;
>> + struct clk *clk;
>> + spinlock_t lock;
>> + int num_channels;
>> + struct rcar_gen2_channel *channels;
>> +};
>> +
>> +static int rcar_gen2_phy_init(struct phy *p)
>> +{
>> + struct rcar_gen2_phy *phy = phy_get_drvdata(p);
>> + struct rcar_gen2_channel *channel = phy->channel;
>> + struct rcar_gen2_phy_driver *drv = channel->drv;
>> + unsigned long flags;
>> + u32 ugctrl2;
>> +
>> + /*
>> + * Try to acquire exclusive access to PHY. The first driver calling
>> + * phy_init() on a given channel wins, and all attempts to use another
>> + * PHY on this channel will fail until phy_exit() is called by the first
>> + * driver. Achieving this with cmpxcgh() should be SMP-safe.
>> + */
>> + if (cmpxchg(&channel->selected_phy, -1, phy->number) != -1)
>> + return -EBUSY;
> This should be done in phy_get no?
No, if you mean the of_xlate() method: I need a place to release the lock
which I wouldn't have in this case.
If you mean modifying _of_phy_get(), it has no notion of channels and
probably shouldn't have since the channels are a special case for this driver
(and maybe some others) ...
> Can we add this in phy-core? There might be other users who want to have
> exclusive access within the same phy provider.
The exclusive access is not within the provider in my case, it's within a
channel (each of which has a corresponding DT subnode), so I don't think it's
well representable in the phy-core. I'm not using your suggested
subnode-per-PHY representation since it doesn't really fit my case well...
> Rest of it looks fine to me.
Thanks.
> Thanks
> Kishon
WBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: Kishon Vijay Abraham I <kishon@ti.com>,
robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
grant.likely@linaro.org, devicetree@vger.kernel.org
Cc: rdunlap@infradead.org, linux-doc@vger.kernel.org,
linux-sh@vger.kernel.org, linux-usb@vger.kernel.org
Subject: Re: [PATCH v5] phy: Renesas R-Car Gen2 PHY driver
Date: Fri, 05 Sep 2014 22:46:29 +0400 [thread overview]
Message-ID: <540A0505.5060008@cogentembedded.com> (raw)
In-Reply-To: <53F4B3E7.3030700@ti.com>
Hello.
On 08/20/2014 06:42 PM, Kishon Vijay Abraham I wrote:
Sorry for the delayed reply, I was busy in other kernel areas. Should have
replied yesterday though...
[...]
>> Index: linux-phy/drivers/phy/phy-rcar-gen2.c
>> ===================================================================
>> --- /dev/null
>> +++ linux-phy/drivers/phy/phy-rcar-gen2.c
>> @@ -0,0 +1,341 @@
>> +/*
>> + * Renesas R-Car Gen2 PHY driver
>> + *
>> + * Copyright (C) 2014 Renesas Solutions Corp.
>> + * Copyright (C) 2014 Cogent Embedded, Inc.
>> + *
>> + * 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/delay.h>
>> +#include <linux/io.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/spinlock.h>
>> +
>> +#include <asm/cmpxchg.h>
>> +
>> +#define USBHS_LPSTS 0x02
>> +#define USBHS_UGCTRL 0x80
>> +#define USBHS_UGCTRL2 0x84
>> +#define USBHS_UGSTS 0x88 /* The manuals have 0x90 */
>> +
>> +/* Low Power Status register (LPSTS) */
>> +#define USBHS_LPSTS_SUSPM 0x4000
>> +
>> +/* USB General control register (UGCTRL) */
>> +#define USBHS_UGCTRL_CONNECT 0x00000004
>> +#define USBHS_UGCTRL_PLLRESET 0x00000001
>> +
>> +/* USB General control register 2 (UGCTRL2) */
>> +#define USBHS_UGCTRL2_USB2SEL 0x80000000
>> +#define USBHS_UGCTRL2_USB2SEL_PCI 0x00000000
>> +#define USBHS_UGCTRL2_USB2SEL_USB30 0x80000000
>> +#define USBHS_UGCTRL2_USB0SEL 0x00000030
>> +#define USBHS_UGCTRL2_USB0SEL_PCI 0x00000010
>> +#define USBHS_UGCTRL2_USB0SEL_HS_USB 0x00000030
>> +
>> +/* USB General status register (UGSTS) */
>> +#define USBHS_UGSTS_LOCK 0x00000300 /* The manuals have 0x3 */
>> +
>> +#define PHYS_PER_CHANNEL 2
>> +
>> +struct rcar_gen2_phy {
>> + struct phy *phy;
>> + struct rcar_gen2_channel *channel;
>> + int number;
>> + u32 select_value;
>> +};
>> +
>> +struct rcar_gen2_channel {
>> + struct device_node *of_node;
>> + struct rcar_gen2_phy_driver *drv;
>> + struct rcar_gen2_phy phys[PHYS_PER_CHANNEL];
>> + int selected_phy;
>> + u32 select_mask;
>> +};
>> +
>> +struct rcar_gen2_phy_driver {
>> + void __iomem *base;
>> + struct clk *clk;
>> + spinlock_t lock;
>> + int num_channels;
>> + struct rcar_gen2_channel *channels;
>> +};
>> +
>> +static int rcar_gen2_phy_init(struct phy *p)
>> +{
>> + struct rcar_gen2_phy *phy = phy_get_drvdata(p);
>> + struct rcar_gen2_channel *channel = phy->channel;
>> + struct rcar_gen2_phy_driver *drv = channel->drv;
>> + unsigned long flags;
>> + u32 ugctrl2;
>> +
>> + /*
>> + * Try to acquire exclusive access to PHY. The first driver calling
>> + * phy_init() on a given channel wins, and all attempts to use another
>> + * PHY on this channel will fail until phy_exit() is called by the first
>> + * driver. Achieving this with cmpxcgh() should be SMP-safe.
>> + */
>> + if (cmpxchg(&channel->selected_phy, -1, phy->number) != -1)
>> + return -EBUSY;
> This should be done in phy_get no?
No, if you mean the of_xlate() method: I need a place to release the lock
which I wouldn't have in this case.
If you mean modifying _of_phy_get(), it has no notion of channels and
probably shouldn't have since the channels are a special case for this driver
(and maybe some others) ...
> Can we add this in phy-core? There might be other users who want to have
> exclusive access within the same phy provider.
The exclusive access is not within the provider in my case, it's within a
channel (each of which has a corresponding DT subnode), so I don't think it's
well representable in the phy-core. I'm not using your suggested
subnode-per-PHY representation since it doesn't really fit my case well...
> Rest of it looks fine to me.
Thanks.
> Thanks
> Kishon
WBR, Sergei
next prev parent reply other threads:[~2014-09-05 18:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-22 19:27 [PATCH v5] phy: Renesas R-Car Gen2 PHY driver Sergei Shtylyov
2014-07-22 19:27 ` Sergei Shtylyov
2014-08-18 22:24 ` Sergei Shtylyov
2014-08-18 22:24 ` Sergei Shtylyov
2014-08-19 6:47 ` Kishon Vijay Abraham I
2014-08-19 6:59 ` Kishon Vijay Abraham I
2014-08-20 14:42 ` Kishon Vijay Abraham I
2014-08-20 14:54 ` Kishon Vijay Abraham I
2014-09-05 18:46 ` Sergei Shtylyov [this message]
2014-09-05 18:46 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=540A0505.5060008@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=grant.likely@linaro.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=kishon@ti.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=rdunlap@infradead.org \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.