linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: nm@ti.com (Nishanth Menon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
Date: Wed, 18 Jun 2014 22:17:34 -0500	[thread overview]
Message-ID: <53A2564E.2080600@ti.com> (raw)
In-Reply-To: <20140619030520.GA13805@saruman.home>

On 06/18/2014 10:05 PM, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Jun 18, 2014 at 09:26:01PM -0500, Nishanth Menon wrote:
>> On 06/18/2014 06:19 PM, Felipe Balbi wrote:
>> [...]
>>>>>>> Add support for TI's AM437x StarterKit Evaluation
>>>>>>> Module.
>>>>>>
>>>>>> is there a link for this platform?
>>>>>
>>>>> internal only
>>>>
>>>> but will eventually be sold externally? I assume this is not an TI
>>>
>>> probably, but there's nothing public yet.
>>>
>>>> internal only board.
>>>
>>> correct assumption for all I know.
>>
>> Yikes.. ok.. I'd let Tony et.al make the call on this, I guess.
> 
> would we really block a DTS just because there's no public wiki page
> available (yet) ?
> 
> Sounds a bit extreme to me.

If this is an TI internal board without anyone outside that a few
select developers being able to get and work on it... I am a bit
skeptical on upstream kernel support and burden for forseeable future
in ensuring it is tested and continually maintained. if it an
one-off.. maybe fork might be good enough.. upstream not too attractive.

I mean, if it is targeted to be sold eventually, I have no objections
or blocks - just make it clear in commit message. I can imagine folks
wondering what the heck this is and googling without results(just like
I did).

[...]

>>>>>>> +	cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
>>>>>>> +};
>>>>>>> +
>>>>>>> +&usb2_phy1 {
>>>>>>> +	status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&usb1 {
>>>>>>> +	dr_mode = "peripheral";
>>>>>>> +	status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&usb2_phy2 {
>>>>>>> +	status = "okay";
>>>>>>> +};
>>>>>>> +
>>>>>>> +&usb2 {
>>>>>>> +	dr_mode = "host";
>>>>>>> +	status = "okay";
>>>>>>> +};
>>>>>> none of the above need pinctrl? no regulator supplies?
>>>>>
>>>>> pins in default states, drivers don't use regulators.
>>>>
>>>> USB works without a supply? even a fixed voltage supply? that is
>>>> weird.
>>>
>>> take a look at the minicom output I posted if you don't believe. Well,
>>> to be exact, tps63010 [1] is the one which generates the regulated V5_0D
>>> which is used as VBUS_USB. The enable pin in that device is tied to the
>>> 3v3 rail (dcdc4 regulator in the PMIC as most everything else) but
>>> there's no way (otherwise) to control that thing. There's no control
>>> bus, no way to write a driver.
>>>
>>> Since the board will anyways turn off if you disable the 3v3 rail, it's
>>> pretty much pointless to figure out a hack just to add this to DTS.
>>>
>>> [1] http://www.ti.com/product/TPS63010
>>
>> I am sure to trust you on the test log :) ->  but then from dts description
>> perspective, it is good if we describe the supplies, even as a always on
>> fixed-regulator. We had instances like 2430SDP ethernet where... umm... we
>> originally missed describing ethernet supply and boom, one fine morning, no
>> more nfs filesystem - I mean, it is a one off scenario there, but describing
>> regulators helps us atleast understand the power tree of the board a little
>> better.
>>
>> Again, no strong opinions on my side, it is a good thing to do is all
>> I feel about it.
> 
> you mean something like:
> 
> 	V5_0D: fixedregulator at 0 {
> 		compatible = "regulator-fixed";
> 		regulator-name = "V5_0D";
> 		regulator-min-microvolt = <5000000>;
> 		regulator-max-microvolt = <5000000>;
> 		regulator-boot-on;
> 		regulator-always-on;
> 		vin-supply = <&dcdc4>;
> 	};
> 
> 	VBUS_USB: fixedregulator at 1 {
> 		compatible = "regulator-fixed";
> 		regulator-name = "VBUS_USB";
> 		regulator-min-microvolt = <5000000>;
> 		regulator-max-microvolt = <5000000>;
> 		regulator-boot-on;
> 		regulator-always-on;
> 		vin-supply = <&V5_0D>;
> 	};
> 
> I can add that, but note that it's *solely* to make sysfs look nice. And
> if that's the case, most likely *every* DTS file in tree today as
> incomplete. OTOH, I really consider this to be hugely unnecessary
> because of the fact that board will turn off if 3v3 (dcdc4) is disabled.
> 


Yes - something along those lines - Again, no strong opinions on my
side for these - just that it is a good thing to model in and may help
drivers where can use the awareness.

Regards,
Nishanth Menon

  reply	other threads:[~2014-06-19  3:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-18 15:43 [PATCH v2 0/2] arm: dts: add support for am437x sk Felipe Balbi
2014-06-18 15:43 ` [PATCH v2 1/2] arm: dts: am4372: let boards enable RTC and Watchdog Felipe Balbi
2014-06-18 15:55   ` Nishanth Menon
2014-06-18 19:25     ` Felipe Balbi
2014-06-18 21:43       ` Nishanth Menon
2014-06-18 21:51         ` Felipe Balbi
2014-06-18 21:55           ` Nishanth Menon
2014-06-18 15:43 ` [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit Felipe Balbi
2014-06-18 16:14   ` Nishanth Menon
2014-06-18 19:31     ` Felipe Balbi
2014-06-18 21:54       ` Nishanth Menon
2014-06-18 23:19         ` Felipe Balbi
2014-06-18 23:23           ` Felipe Balbi
2014-06-19  2:26           ` Nishanth Menon
2014-06-19  3:05             ` Felipe Balbi
2014-06-19  3:17               ` Nishanth Menon [this message]
2014-06-19  4:02                 ` Felipe Balbi

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=53A2564E.2080600@ti.com \
    --to=nm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).