All of lore.kernel.org
 help / color / mirror / Atom feed
From: kishon@ti.com (Kishon Vijay Abraham I)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/5] phy: berlin-sata: Move PHY_BASE into private data struct
Date: Mon, 27 Oct 2014 17:57:11 +0530	[thread overview]
Message-ID: <544E3A1F.2060304@ti.com> (raw)
In-Reply-To: <20141024202510.GK11455@saruman>

Hi,

On Saturday 25 October 2014 01:55 AM, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Oct 24, 2014 at 10:14:55PM +0200, Sebastian Hesselbarth wrote:
>> On 21.10.2014 11:40, Sebastian Hesselbarth wrote:
>>> On 10/21/2014 11:33 AM, Kishon Vijay Abraham I wrote:
>>>> On Tuesday 21 October 2014 02:37 PM, Sebastian Hesselbarth wrote:
>>>>> Currently, Berlin SATA PHY driver assumes PHY_BASE address being
>>>>> constant. While this PHY_BASE is correct for BG2Q, older BG2 PHY_BASE
>>>>> is different. Prepare the driver for BG2 support by moving the phy_base
>>>>> into private driver data.
>>>>>
>>>>> Acked-by: Antoine T?nart <antoine.tenart@free-electrons.com>
>>>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>> ...
>>>>> ---
>>>>>  drivers/phy/phy-berlin-sata.c | 42
>>>>> ++++++++++++++++++++++++++++--------------
>>>>>  1 file changed, 28 insertions(+), 14 deletions(-)
>>>>>
>>>>> diff --git a/drivers/phy/phy-berlin-sata.c
>>>>> b/drivers/phy/phy-berlin-sata.c
>>>>> index 69ced52d72aa..9682b0f66177 100644
>>>>> --- a/drivers/phy/phy-berlin-sata.c
>>>>> +++ b/drivers/phy/phy-berlin-sata.c
>>>>> @@ -30,7 +30,7 @@
>>>>>  #define MBUS_WRITE_REQUEST_SIZE_128    (BIT(2) << 16)
>>>>>  #define MBUS_READ_REQUEST_SIZE_128    (BIT(2) << 19)
>>>>>
>>>>> -#define PHY_BASE        0x200
>>>>> +#define BG2Q_PHY_BASE        0x200
>>> [...]
>>>>> +static u32 bg2q_sata_phy_base = BG2Q_PHY_BASE;
>>>>> +
>>>>> +static const struct of_device_id phy_berlin_sata_of_match[] = {
>>>>> +    {
>>>>> +        .compatible = "marvell,berlin2q-sata-phy",
>>>>> +        .data = &bg2q_sata_phy_base,
>>>>
>>>> Can't the base directly come from dt?
>>>
>>> You are suggesting a "marvell,phy-base-address" property, right?
>>> I have no strong opinion about it, I accept your call (or DT maintainer
>>> ones).
>>
>> Kishon,
>>
>> I still have the DT patches for BG2Q queued up for v3.19 (I missed the
>> arm-soc merge window for v3.18). That means, there has been no release
>> with the phy binding used and I can rework a little more.
>>
>> Can you please confirm that you want a DT property for the phy base address,
>> e.g. marvell,phy-base-address = <{0x200,0x80}> ?
>>
>> If so, I'd also rename the compatible from berlin2q-sata-phy to more
>> generic berlin-sata-phy.
> 
> I think what Kishon is asking, is why this 0x200 offset isn't already on
> reg. so that instead of, e.g.:
> 
> 	reg = <0x40000000 0x1000>;
> 
> you would have:
> 
> 	reg = <0x40000200 0x1000>;

I had something similar to what Sebastian suggested in mind. I think phy_base
is used for a different reason and can't be directly used in 'reg'.

Thanks
Kishon

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
To: balbi-l0cyMroinI0@public.gmane.org,
	Sebastian Hesselbarth
	<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "Antoine Ténart"
	<antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v2 1/5] phy: berlin-sata: Move PHY_BASE into private data struct
Date: Mon, 27 Oct 2014 17:57:11 +0530	[thread overview]
Message-ID: <544E3A1F.2060304@ti.com> (raw)
In-Reply-To: <20141024202510.GK11455@saruman>

Hi,

On Saturday 25 October 2014 01:55 AM, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Oct 24, 2014 at 10:14:55PM +0200, Sebastian Hesselbarth wrote:
>> On 21.10.2014 11:40, Sebastian Hesselbarth wrote:
>>> On 10/21/2014 11:33 AM, Kishon Vijay Abraham I wrote:
>>>> On Tuesday 21 October 2014 02:37 PM, Sebastian Hesselbarth wrote:
>>>>> Currently, Berlin SATA PHY driver assumes PHY_BASE address being
>>>>> constant. While this PHY_BASE is correct for BG2Q, older BG2 PHY_BASE
>>>>> is different. Prepare the driver for BG2 support by moving the phy_base
>>>>> into private driver data.
>>>>>
>>>>> Acked-by: Antoine Ténart <antoine.tenart-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>> ...
>>>>> ---
>>>>>  drivers/phy/phy-berlin-sata.c | 42
>>>>> ++++++++++++++++++++++++++++--------------
>>>>>  1 file changed, 28 insertions(+), 14 deletions(-)
>>>>>
>>>>> diff --git a/drivers/phy/phy-berlin-sata.c
>>>>> b/drivers/phy/phy-berlin-sata.c
>>>>> index 69ced52d72aa..9682b0f66177 100644
>>>>> --- a/drivers/phy/phy-berlin-sata.c
>>>>> +++ b/drivers/phy/phy-berlin-sata.c
>>>>> @@ -30,7 +30,7 @@
>>>>>  #define MBUS_WRITE_REQUEST_SIZE_128    (BIT(2) << 16)
>>>>>  #define MBUS_READ_REQUEST_SIZE_128    (BIT(2) << 19)
>>>>>
>>>>> -#define PHY_BASE        0x200
>>>>> +#define BG2Q_PHY_BASE        0x200
>>> [...]
>>>>> +static u32 bg2q_sata_phy_base = BG2Q_PHY_BASE;
>>>>> +
>>>>> +static const struct of_device_id phy_berlin_sata_of_match[] = {
>>>>> +    {
>>>>> +        .compatible = "marvell,berlin2q-sata-phy",
>>>>> +        .data = &bg2q_sata_phy_base,
>>>>
>>>> Can't the base directly come from dt?
>>>
>>> You are suggesting a "marvell,phy-base-address" property, right?
>>> I have no strong opinion about it, I accept your call (or DT maintainer
>>> ones).
>>
>> Kishon,
>>
>> I still have the DT patches for BG2Q queued up for v3.19 (I missed the
>> arm-soc merge window for v3.18). That means, there has been no release
>> with the phy binding used and I can rework a little more.
>>
>> Can you please confirm that you want a DT property for the phy base address,
>> e.g. marvell,phy-base-address = <{0x200,0x80}> ?
>>
>> If so, I'd also rename the compatible from berlin2q-sata-phy to more
>> generic berlin-sata-phy.
> 
> I think what Kishon is asking, is why this 0x200 offset isn't already on
> reg. so that instead of, e.g.:
> 
> 	reg = <0x40000000 0x1000>;
> 
> you would have:
> 
> 	reg = <0x40000200 0x1000>;

I had something similar to what Sebastian suggested in mind. I think phy_base
is used for a different reason and can't be directly used in 'reg'.

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: <balbi@ti.com>, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: "Antoine Ténart" <antoine.tenart@free-electrons.com>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] phy: berlin-sata: Move PHY_BASE into private data struct
Date: Mon, 27 Oct 2014 17:57:11 +0530	[thread overview]
Message-ID: <544E3A1F.2060304@ti.com> (raw)
In-Reply-To: <20141024202510.GK11455@saruman>

Hi,

On Saturday 25 October 2014 01:55 AM, Felipe Balbi wrote:
> Hi,
> 
> On Fri, Oct 24, 2014 at 10:14:55PM +0200, Sebastian Hesselbarth wrote:
>> On 21.10.2014 11:40, Sebastian Hesselbarth wrote:
>>> On 10/21/2014 11:33 AM, Kishon Vijay Abraham I wrote:
>>>> On Tuesday 21 October 2014 02:37 PM, Sebastian Hesselbarth wrote:
>>>>> Currently, Berlin SATA PHY driver assumes PHY_BASE address being
>>>>> constant. While this PHY_BASE is correct for BG2Q, older BG2 PHY_BASE
>>>>> is different. Prepare the driver for BG2 support by moving the phy_base
>>>>> into private driver data.
>>>>>
>>>>> Acked-by: Antoine Ténart <antoine.tenart@free-electrons.com>
>>>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>> ...
>>>>> ---
>>>>>  drivers/phy/phy-berlin-sata.c | 42
>>>>> ++++++++++++++++++++++++++++--------------
>>>>>  1 file changed, 28 insertions(+), 14 deletions(-)
>>>>>
>>>>> diff --git a/drivers/phy/phy-berlin-sata.c
>>>>> b/drivers/phy/phy-berlin-sata.c
>>>>> index 69ced52d72aa..9682b0f66177 100644
>>>>> --- a/drivers/phy/phy-berlin-sata.c
>>>>> +++ b/drivers/phy/phy-berlin-sata.c
>>>>> @@ -30,7 +30,7 @@
>>>>>  #define MBUS_WRITE_REQUEST_SIZE_128    (BIT(2) << 16)
>>>>>  #define MBUS_READ_REQUEST_SIZE_128    (BIT(2) << 19)
>>>>>
>>>>> -#define PHY_BASE        0x200
>>>>> +#define BG2Q_PHY_BASE        0x200
>>> [...]
>>>>> +static u32 bg2q_sata_phy_base = BG2Q_PHY_BASE;
>>>>> +
>>>>> +static const struct of_device_id phy_berlin_sata_of_match[] = {
>>>>> +    {
>>>>> +        .compatible = "marvell,berlin2q-sata-phy",
>>>>> +        .data = &bg2q_sata_phy_base,
>>>>
>>>> Can't the base directly come from dt?
>>>
>>> You are suggesting a "marvell,phy-base-address" property, right?
>>> I have no strong opinion about it, I accept your call (or DT maintainer
>>> ones).
>>
>> Kishon,
>>
>> I still have the DT patches for BG2Q queued up for v3.19 (I missed the
>> arm-soc merge window for v3.18). That means, there has been no release
>> with the phy binding used and I can rework a little more.
>>
>> Can you please confirm that you want a DT property for the phy base address,
>> e.g. marvell,phy-base-address = <{0x200,0x80}> ?
>>
>> If so, I'd also rename the compatible from berlin2q-sata-phy to more
>> generic berlin-sata-phy.
> 
> I think what Kishon is asking, is why this 0x200 offset isn't already on
> reg. so that instead of, e.g.:
> 
> 	reg = <0x40000000 0x1000>;
> 
> you would have:
> 
> 	reg = <0x40000200 0x1000>;

I had something similar to what Sebastian suggested in mind. I think phy_base
is used for a different reason and can't be directly used in 'reg'.

Thanks
Kishon

  parent reply	other threads:[~2014-10-27 12:27 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21  9:07 [PATCH v2 0/5] Berlin BG2 AHCI and SATA PHY Sebastian Hesselbarth
2014-10-21  9:07 ` Sebastian Hesselbarth
2014-10-21  9:07 ` Sebastian Hesselbarth
2014-10-21  9:07 ` [PATCH v2 1/5] phy: berlin-sata: Move PHY_BASE into private data struct Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:33   ` Kishon Vijay Abraham I
2014-10-21  9:33     ` Kishon Vijay Abraham I
2014-10-21  9:40     ` Sebastian Hesselbarth
2014-10-21  9:40       ` Sebastian Hesselbarth
2014-10-21  9:40       ` Sebastian Hesselbarth
2014-10-24 20:14       ` Sebastian Hesselbarth
2014-10-24 20:14         ` Sebastian Hesselbarth
2014-10-24 20:14         ` Sebastian Hesselbarth
2014-10-24 20:25         ` Felipe Balbi
2014-10-24 20:25           ` Felipe Balbi
2014-10-24 20:35           ` Sebastian Hesselbarth
2014-10-24 20:35             ` Sebastian Hesselbarth
2014-10-27 12:27           ` Kishon Vijay Abraham I [this message]
2014-10-27 12:27             ` Kishon Vijay Abraham I
2014-10-27 12:27             ` Kishon Vijay Abraham I
2014-10-27 18:32             ` Sebastian Hesselbarth
2014-10-27 18:32               ` Sebastian Hesselbarth
2014-10-30  5:27               ` Kishon Vijay Abraham I
2014-10-30  5:27                 ` Kishon Vijay Abraham I
2014-10-30  5:27                 ` Kishon Vijay Abraham I
2014-10-21  9:07 ` [PATCH v2 2/5] phy: berlin-sata: Add support for BG2 SATA PHY Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:07 ` [PATCH v2 3/5] phy: berlin-sata: Document BG2 compatible Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:07 ` [PATCH v2 4/5] ARM: berlin: Add AHCI and SATA PHY nodes to BG2 Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:07 ` [PATCH v2 5/5] ARM: berlin: Enable SATA on Sony NSZ-GS7 Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-21  9:07   ` Sebastian Hesselbarth
2014-10-30 10:21 ` [PATCH v3 0/5] Berlin BG2 AHCI and SATA PHY Sebastian Hesselbarth
2014-10-30 10:21   ` Sebastian Hesselbarth
2014-10-30 10:21   ` Sebastian Hesselbarth
2014-10-30 10:21   ` [PATCH v3 1/5] phy: berlin-sata: Move PHY_BASE into private data struct Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-10-30 10:21   ` [PATCH v3 2/5] phy: berlin-sata: Add support for BG2 SATA PHY Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-10-30 10:21   ` [PATCH v3 3/5] phy: berlin-sata: Document BG2 compatible Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-10-30 10:21   ` [PATCH v3 4/5] ARM: berlin: Add AHCI and SATA PHY nodes to BG2 Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-11-11 23:23     ` Sebastian Hesselbarth
2014-11-11 23:23       ` Sebastian Hesselbarth
2014-11-11 23:23       ` Sebastian Hesselbarth
2014-10-30 10:21   ` [PATCH v3 5/5] ARM: berlin: Enable SATA on Sony NSZ-GS7 Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth
2014-10-30 10:21     ` Sebastian Hesselbarth

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=544E3A1F.2060304@ti.com \
    --to=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.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.