All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Jack Pham <jackp@codeaurora.org>
Cc: devicetree@vger.kernel.org, linux-usb@vger.kernel.org,
	Bjorn Andersson <bjorn.andersson@sonymobile.com>,
	linux-arm-msm@vger.kernel.org, Kumar Gala <galak@codeaurora.org>,
	linux-kernel@vger.kernel.org, Felipe Balbi <balbi@ti.com>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	"Ivan T. Ivanov" <iivanov@mm-sol.com>,
	Andy Gross <agross@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [Patch v9 1/3] usb: dwc3: qcom: Add device tree binding
Date: Tue, 16 Sep 2014 13:29:21 -0500	[thread overview]
Message-ID: <20140916182920.GF19010@saruman.home> (raw)
In-Reply-To: <20140916181543.GA19101@usblab-sd-06.qualcomm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1520 bytes --]

Hi,

On Tue, Sep 16, 2014 at 11:15:43AM -0700, Jack Pham wrote:
> Hi Andy,
> 
> On Fri, Sep 12, 2014 at 02:28:06PM -0500, Andy Gross wrote:
> > +Example device nodes:
> > +
> > +		hs_phy: phy@100f8800 {
> > +			compatible = "qcom,dwc3-hs-usb-phy";
> > +			reg = <0x100f8800 0x30>;
> 
> Just wanted to point out that in our downstream code, the glue
> device/driver, i.e. "qcom,dwc3", does claim an entire register region
> that encompasses the same registers used by these PHYs. I noticed you're
> not adding a reg resource to the glue node below in this patchset. In
> order to allow multiple devices to use the overlapping regions, we avoid
> calling devm_ioremap_resource() and instead call devm_ioremap_nocache()
> directly which bypasses the request_mem_region() call, which I don't
> think is an entirely correct thing to do.
> 
> On the other hand I'm trying to think of use cases on our other SOCs
> (MSM8974, APQ8084) where the glue actually would need access to the same
> or adjacent IO registers that couldn't just be handled directly by these
> PHY drivers. Should we accommodate for the potential of overlapping
> regions or should we just hold the line here and maybe only expose with
> finer granularity the registers that will actually be needed by the PHYs
> & glue respectively?

I prefer to keep things separated. Glue only needs to access whatever
belongs to glue. If a register related to PHY settings, it should be in
the PHY address space.

cheers

-- 
balbi

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: balbi@ti.com (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [Patch v9 1/3] usb: dwc3: qcom: Add device tree binding
Date: Tue, 16 Sep 2014 13:29:21 -0500	[thread overview]
Message-ID: <20140916182920.GF19010@saruman.home> (raw)
In-Reply-To: <20140916181543.GA19101@usblab-sd-06.qualcomm.com>

Hi,

On Tue, Sep 16, 2014 at 11:15:43AM -0700, Jack Pham wrote:
> Hi Andy,
> 
> On Fri, Sep 12, 2014 at 02:28:06PM -0500, Andy Gross wrote:
> > +Example device nodes:
> > +
> > +		hs_phy: phy at 100f8800 {
> > +			compatible = "qcom,dwc3-hs-usb-phy";
> > +			reg = <0x100f8800 0x30>;
> 
> Just wanted to point out that in our downstream code, the glue
> device/driver, i.e. "qcom,dwc3", does claim an entire register region
> that encompasses the same registers used by these PHYs. I noticed you're
> not adding a reg resource to the glue node below in this patchset. In
> order to allow multiple devices to use the overlapping regions, we avoid
> calling devm_ioremap_resource() and instead call devm_ioremap_nocache()
> directly which bypasses the request_mem_region() call, which I don't
> think is an entirely correct thing to do.
> 
> On the other hand I'm trying to think of use cases on our other SOCs
> (MSM8974, APQ8084) where the glue actually would need access to the same
> or adjacent IO registers that couldn't just be handled directly by these
> PHY drivers. Should we accommodate for the potential of overlapping
> regions or should we just hold the line here and maybe only expose with
> finer granularity the registers that will actually be needed by the PHYs
> & glue respectively?

I prefer to keep things separated. Glue only needs to access whatever
belongs to glue. If a register related to PHY settings, it should be in
the PHY address space.

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140916/b45ffe5a/attachment.sig>

WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@ti.com>
To: Jack Pham <jackp@codeaurora.org>
Cc: Andy Gross <agross@codeaurora.org>, Felipe Balbi <balbi@ti.com>,
	<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	Kumar Gala <galak@codeaurora.org>,
	<linux-arm-msm@vger.kernel.org>, <linux-usb@vger.kernel.org>,
	"Ivan T. Ivanov" <iivanov@mm-sol.com>,
	Bjorn Andersson <bjorn.andersson@sonymobile.com>
Subject: Re: [Patch v9 1/3] usb: dwc3: qcom: Add device tree binding
Date: Tue, 16 Sep 2014 13:29:21 -0500	[thread overview]
Message-ID: <20140916182920.GF19010@saruman.home> (raw)
In-Reply-To: <20140916181543.GA19101@usblab-sd-06.qualcomm.com>

[-- Attachment #1: Type: text/plain, Size: 1520 bytes --]

Hi,

On Tue, Sep 16, 2014 at 11:15:43AM -0700, Jack Pham wrote:
> Hi Andy,
> 
> On Fri, Sep 12, 2014 at 02:28:06PM -0500, Andy Gross wrote:
> > +Example device nodes:
> > +
> > +		hs_phy: phy@100f8800 {
> > +			compatible = "qcom,dwc3-hs-usb-phy";
> > +			reg = <0x100f8800 0x30>;
> 
> Just wanted to point out that in our downstream code, the glue
> device/driver, i.e. "qcom,dwc3", does claim an entire register region
> that encompasses the same registers used by these PHYs. I noticed you're
> not adding a reg resource to the glue node below in this patchset. In
> order to allow multiple devices to use the overlapping regions, we avoid
> calling devm_ioremap_resource() and instead call devm_ioremap_nocache()
> directly which bypasses the request_mem_region() call, which I don't
> think is an entirely correct thing to do.
> 
> On the other hand I'm trying to think of use cases on our other SOCs
> (MSM8974, APQ8084) where the glue actually would need access to the same
> or adjacent IO registers that couldn't just be handled directly by these
> PHY drivers. Should we accommodate for the potential of overlapping
> regions or should we just hold the line here and maybe only expose with
> finer granularity the registers that will actually be needed by the PHYs
> & glue respectively?

I prefer to keep things separated. Glue only needs to access whatever
belongs to glue. If a register related to PHY settings, it should be in
the PHY address space.

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-09-16 18:29 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-12 19:28 [Patch v9 0/3] DWC3 USB support for Qualcomm platform Andy Gross
2014-09-12 19:28 ` Andy Gross
2014-09-12 19:28 ` Andy Gross
2014-09-12 19:28 ` [Patch v9 1/3] usb: dwc3: qcom: Add device tree binding Andy Gross
2014-09-12 19:28   ` Andy Gross
2014-09-12 19:28   ` Andy Gross
2014-09-16 18:15   ` Jack Pham
2014-09-16 18:15     ` Jack Pham
2014-09-16 18:29     ` Felipe Balbi [this message]
2014-09-16 18:29       ` Felipe Balbi
2014-09-16 18:29       ` Felipe Balbi
2014-09-12 19:28 ` [Patch v9 2/3] usb: dwc3: Add Qualcomm DWC3 glue layer driver Andy Gross
2014-09-12 19:28   ` Andy Gross
     [not found]   ` <CAMf-jSm2fPPstFD2h4-gG=MCDty34f-O0ooizDEKyQUd3+CxGQ@mail.gmail.com>
2014-09-12 20:20     ` Felipe Balbi
2014-09-12 20:20       ` Felipe Balbi
2014-09-12 20:20       ` Felipe Balbi
2014-09-12 20:25       ` Pramod Gurav
2014-09-12 20:25         ` Pramod Gurav
2014-09-12 20:29         ` Felipe Balbi
2014-09-12 20:29           ` Felipe Balbi
2014-09-12 20:29           ` Felipe Balbi
     [not found]           ` <20140912202942.GC25500-HgARHv6XitL9zxVx7UNMDg@public.gmane.org>
2014-09-12 20:33             ` Pramod Gurav
2014-09-12 20:33               ` Pramod Gurav
2014-09-12 20:33               ` Pramod Gurav
2014-09-12 19:28 ` [Patch v9 3/3] phy: Add Qualcomm DWC3 HS/SS PHY driver Andy Gross
2014-09-12 19:28   ` Andy Gross
2014-09-13  6:46   ` Kishon Vijay Abraham I
2014-09-13  6:46     ` Kishon Vijay Abraham I
2014-09-13  6:46     ` Kishon Vijay Abraham I
2014-09-14  2:24     ` Felipe Balbi
2014-09-14  2:24       ` Felipe Balbi
2014-09-14  2:24       ` Felipe Balbi
2014-09-15  6:37       ` Kishon Vijay Abraham I
2014-09-15  6:37         ` Kishon Vijay Abraham I
2014-09-15  6:37         ` Kishon Vijay Abraham I
2014-09-16 18:27   ` Jack Pham
2014-09-16 18:27     ` Jack Pham
     [not found]     ` <20140916182752.GB19101-NjF/qFWh7jSrUKQWM4GlyCPyLMyjRtWwAL8bYrjMMd8@public.gmane.org>
2014-09-16 20:39       ` Andy Gross
2014-09-16 20:39         ` Andy Gross
2014-09-16 20:39         ` Andy Gross
     [not found]   ` <1410550088-8754-4-git-send-email-agross-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-01-22 18:59     ` Jack Pham
2015-01-22 18:59       ` Jack Pham
2015-01-22 18:59       ` Jack Pham
2015-01-22 21:44       ` Andy Gross
2015-01-22 21:44         ` Andy Gross

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=20140916182920.GF19010@saruman.home \
    --to=balbi@ti.com \
    --cc=agross@codeaurora.org \
    --cc=bjorn.andersson@sonymobile.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=iivanov@mm-sol.com \
    --cc=jackp@codeaurora.org \
    --cc=kishon@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.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.