All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joonyoung Shim <jy0922.shim@samsung.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Vivek Gautam <gautamvivek1987@gmail.com>,
	yulgon.kim@samsung.com, kgene.kim@samsung.com,
	prashanth.g@samsung.com, olofj@google.com,
	devicetree-discuss@lists.ozlabs.org, l.majewski@samsung.com,
	joshi@samsung.com, kyungmin.park@samsung.com,
	linux-samsung-soc@vger.kernel.org,
	Vivek Gautam <gautam.vivek@samsung.com>,
	a.kesavan@samsung.com, av.tikhomirov@samsung.com,
	boyko.lee@samsung.com, ajaykumar.rs@samsung.com,
	linux-arm-kernel@lists.infradead.org, m.szyprowski@samsung.com
Subject: Re: [PATCH 2/8 v2] ARM: EXYNOS5: Add machine data for USB 2.0
Date: Wed, 01 Aug 2012 12:02:41 +0900	[thread overview]
Message-ID: <50189C51.8080409@samsung.com> (raw)
In-Reply-To: <201207291311.08012.arnd@arndb.de>

On 07/29/2012 10:11 PM, Arnd Bergmann wrote:
> On Saturday 28 July 2012, Vivek Gautam wrote:
>>> Can you pleae explain why this is done in the changelog?
>>>
>>> We try hard to do such mappings from the device driver instead,
>>> so I'm surprised that this is necessary fo rthe USB phy.
>>>
>> We are doing the mapping for device address in the driver, but this memory
>> mapping for USB PHY registers that need to be programmed by the software
>> is done here. This is similar to what we see for exynos4 also. Is it
>> something
>> that i can still change? Please suggest.
>
> Yes, I think the USB PHY handling for all exynos chips should be changed
> from an ad-hoc method to a more formal device driver. As I commented
> in another patch of this series, I think the main problem is that
> treat the USB PHY as a property of the "platform", which it really isn't.
>
> We have a bunch of other USB PHY drivers for other platforms that are
> inside of the drivers/usb hierarchy. For all I know, there is no formal
> USB PHY driver API yet, and it seems that it would be a good idea to
> introduce one now, but for now, just move the code to
> drivers/usb/phy/ and make it one file per different kind of PHY.
>

Totally agree. I think that two PHY drivers need for usb2.0 PHY and
usb3.0 PHY in drivers/usb/phy directory. First, let's make usb2.0 PHY
driver for samsung SoCs from phy control codes of arch/arm, then add to
support usb2.0 PHY for exynos5 and make usb3.0 PHY driver for exynos.

Thanks.

WARNING: multiple messages have this Message-ID (diff)
From: jy0922.shim@samsung.com (Joonyoung Shim)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/8 v2] ARM: EXYNOS5: Add machine data for USB 2.0
Date: Wed, 01 Aug 2012 12:02:41 +0900	[thread overview]
Message-ID: <50189C51.8080409@samsung.com> (raw)
In-Reply-To: <201207291311.08012.arnd@arndb.de>

On 07/29/2012 10:11 PM, Arnd Bergmann wrote:
> On Saturday 28 July 2012, Vivek Gautam wrote:
>>> Can you pleae explain why this is done in the changelog?
>>>
>>> We try hard to do such mappings from the device driver instead,
>>> so I'm surprised that this is necessary fo rthe USB phy.
>>>
>> We are doing the mapping for device address in the driver, but this memory
>> mapping for USB PHY registers that need to be programmed by the software
>> is done here. This is similar to what we see for exynos4 also. Is it
>> something
>> that i can still change? Please suggest.
>
> Yes, I think the USB PHY handling for all exynos chips should be changed
> from an ad-hoc method to a more formal device driver. As I commented
> in another patch of this series, I think the main problem is that
> treat the USB PHY as a property of the "platform", which it really isn't.
>
> We have a bunch of other USB PHY drivers for other platforms that are
> inside of the drivers/usb hierarchy. For all I know, there is no formal
> USB PHY driver API yet, and it seems that it would be a good idea to
> introduce one now, but for now, just move the code to
> drivers/usb/phy/ and make it one file per different kind of PHY.
>

Totally agree. I think that two PHY drivers need for usb2.0 PHY and
usb3.0 PHY in drivers/usb/phy directory. First, let's make usb2.0 PHY
driver for samsung SoCs from phy control codes of arch/arm, then add to
support usb2.0 PHY for exynos5 and make usb3.0 PHY driver for exynos.

Thanks.

  reply	other threads:[~2012-08-01  3:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-21 10:32 [PATCH 0/8 v2] EXYNOS5: USB: Add USB 2.0 and USB 3.0 support for exynos5 Vivek Gautam
2012-07-21 10:32 ` Vivek Gautam
2012-07-21 10:32 ` [PATCH 1/8 v2] EXYNOS4: USB: Generalising setup-usb-phy driver for exynos Vivek Gautam
2012-07-21 10:32   ` Vivek Gautam
2012-07-21 10:32 ` [PATCH 2/8 v2] ARM: EXYNOS5: Add machine data for USB 2.0 Vivek Gautam
2012-07-21 10:32   ` Vivek Gautam
2012-07-26 11:24   ` Arnd Bergmann
2012-07-26 11:24     ` Arnd Bergmann
2012-07-28 16:05     ` Vivek Gautam
2012-07-28 16:05       ` Vivek Gautam
2012-07-29 13:11       ` Arnd Bergmann
2012-07-29 13:11         ` Arnd Bergmann
2012-08-01  3:02         ` Joonyoung Shim [this message]
2012-08-01  3:02           ` Joonyoung Shim
2012-07-21 10:32 ` [PATCH 3/8 v2] ARM: EXYNOS5: Add OHCI device from device tree Vivek Gautam
2012-07-21 10:32   ` Vivek Gautam
2012-07-21 10:32 ` [PATCH 4/8 v2] ARM: EXYNOS5: Add EHCI " Vivek Gautam
2012-07-21 10:32   ` Vivek Gautam
2012-07-26 11:57   ` Arnd Bergmann
2012-07-26 11:57     ` Arnd Bergmann
2012-07-28 16:41     ` Vivek Gautam
2012-07-28 16:42       ` Vivek Gautam
2012-07-21 10:32 ` [PATCH 5/8 v2] ARM: EXYNOS5: Add PHY initialization code for usb 2.0 Vivek Gautam
2012-07-21 10:32   ` Vivek Gautam
     [not found]   ` <1342866729-30460-6-git-send-email-gautam.vivek-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2012-07-26 12:08     ` Arnd Bergmann
2012-07-26 12:08       ` Arnd Bergmann
2012-07-21 10:32 ` [PATCH 6/8 v2] ARM: EXYNOS5: Add machine data for USB3.0 Vivek Gautam
2012-07-21 10:32   ` Vivek Gautam
2012-07-21 10:32 ` [PATCH 7/8 v2] ARM: EXYNOS5: Add XHCI device from device tree Vivek Gautam
2012-07-21 10:32   ` Vivek Gautam
2012-07-21 10:32 ` [PATCH 8/8 v2] ARM: EXYNOS5: Add PHY initialization code for usb 3.0 Vivek Gautam
2012-07-21 10:32   ` Vivek Gautam

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=50189C51.8080409@samsung.com \
    --to=jy0922.shim@samsung.com \
    --cc=a.kesavan@samsung.com \
    --cc=ajaykumar.rs@samsung.com \
    --cc=arnd@arndb.de \
    --cc=av.tikhomirov@samsung.com \
    --cc=boyko.lee@samsung.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=gautam.vivek@samsung.com \
    --cc=gautamvivek1987@gmail.com \
    --cc=joshi@samsung.com \
    --cc=kgene.kim@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=l.majewski@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=olofj@google.com \
    --cc=prashanth.g@samsung.com \
    --cc=yulgon.kim@samsung.com \
    /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.