From: Felipe Balbi <hidden> Date: 2014-06-18 15:43:57
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi <redacted>
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
$subject - ARM: dts:
On 06/18/2014 10:43 AM, Felipe Balbi wrote:
quoted hunk
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi <redacted>
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
we might want to fix up any other similar nodes in dtsi as well, no?
examples:
cpu at 0
dispc at 4832a400
Might also be nice to have Fixes: to point out which commit was being
fixed, no?
--
Regards,
Nishanth Menon
From: Felipe Balbi <hidden> Date: 2014-06-18 19:26:30
Hi,
On Wed, Jun 18, 2014 at 10:55:35AM -0500, Nishanth Menon wrote:
$subject - ARM: dts:
On 06/18/2014 10:43 AM, Felipe Balbi wrote:
quoted
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi <redacted>
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi,
On Wed, Jun 18, 2014 at 10:55:35AM -0500, Nishanth Menon wrote:
quoted
$subject - ARM: dts:
On 06/18/2014 10:43 AM, Felipe Balbi wrote:
quoted
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi <redacted>
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Felipe Balbi <hidden> Date: 2014-06-18 21:52:20
Hi,
On Wed, Jun 18, 2014 at 04:43:28PM -0500, Nishanth Menon wrote:
On 06/18/2014 02:25 PM, Felipe Balbi wrote:
quoted
Hi,
On Wed, Jun 18, 2014 at 10:55:35AM -0500, Nishanth Menon wrote:
quoted
$subject - ARM: dts:
On 06/18/2014 10:43 AM, Felipe Balbi wrote:
quoted
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi <redacted>
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Might be good to explicitly configure it - no strong opinions though ->
GPIOs are always good to pinctrl up esp if bootloader screws up at a
later date.
[...]
there's no configuration for this. This pin is a single function.
quoted
quoted
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = "ti,tps65218-dcdc1";
+ /* VDD_CORE limits min of OPP50 and max of OPP100 */
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = "ti,tps65218-dcdc2";
+ /* VDD_MPU limits min of OPP50 and max of OPP_NITRO */
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1378000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = "ti,tps65218-dcdc3";
+ regulator-name = "vdds_ddr";
no voltage ?
has no users in kernel. Also, it comes out with default, and correct,
voltage.
Device tree is description of hardware, not just who uses what in OS of
interest.
you might consider u-boot to use the same device tree at a later date
and having complete details about the hardware is always the norm.
I suggest setting the voltage here to be complete even if there are no
current users.
why wake-gpios? we should be using pinctrl with interrupt-extended to
do wakeup sequence, no?
sure, can you patch the edt driver ? I'll fix the DTS after that gets
merged
If you really want to go down that road, so you could probably help
review the pinctrl patches I posted to enable pinctrl wakeup[1]?
Come on, as of today, there is no ability to suspend AM437x without
doing [1], let alone talk about wakeup gpio vs interrupt-extended. and
do we really want to wakeup from suspend when touch screen is touched?
Do you expect wake-gpio to work even after doing interrupt based
solution? I am no edt driver expert... maybe you can help me here.
Hi,
On Wed, Jun 18, 2014 at 04:43:28PM -0500, Nishanth Menon wrote:
quoted
On 06/18/2014 02:25 PM, Felipe Balbi wrote:
quoted
Hi,
On Wed, Jun 18, 2014 at 10:55:35AM -0500, Nishanth Menon wrote:
quoted
$subject - ARM: dts:
On 06/18/2014 10:43 AM, Felipe Balbi wrote:
quoted
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi <redacted>
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
we might want to fix up any other similar nodes in dtsi as well, no?
examples:
cpu at 0
and why would you want boards to mess with the cpu node ?
cpu-supply = <®ulator>;
for cpufreq.
good point, but does thqt even work with AM437x devices in mainline?
it will once we are done adding a node. context here being - if you are
fixing phandles, please fix them all up.. that is a little nice to do.
I wont argue more on this. I will leave it to maintainers.
--
Regards,
Nishanth Menon
Might be good to explicitly configure it - no strong opinions though
-> GPIOs are always good to pinctrl up esp if bootloader screws up at
a later date.
I find that very unlikely and don't quite like the idea of accessing
registers unnecessarily. OTOH, I don't quite care, to be frank.
what speed are you running this on? -> also can you align these to 1
100kHz ?
Rule of thumb is to do the following: MIN(MAX_FREQ(D1),
MAX_FREQ(D2).... MAX_FREQ(Dn)); where D1..n are all the peripherals on
this i2c bus.
hehe, right.
quoted
quoted
quoted
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = "ti,tps65218-dcdc1";
+ /* VDD_CORE limits min of OPP50 and max of OPP100 */
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = "ti,tps65218-dcdc2";
+ /* VDD_MPU limits min of OPP50 and max of OPP_NITRO */
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1378000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = "ti,tps65218-dcdc3";
+ regulator-name = "vdds_ddr";
no voltage ?
has no users in kernel. Also, it comes out with default, and correct,
voltage.
Device tree is description of hardware, not just who uses what in OS
of interest.
then we should start "fixing" every single DTS in the kernel because I'm
sure even LEDs and keypads are tied to some sort of supply, as is the
case with this board. No driver will use it though.
Also, I couldn't find anywhere which voltage is dcdc3 outputing and
there's no shunt anywhere (other than a 0 ohm resistor) to measure
voltage. So I kinda have my hands tied here.
(goes review schematics)
actually there's 0.05 ohm sense resistor. Hopefully it's easy to access.
you might consider u-boot to use the same device tree at a later date and
having complete details about the hardware is always the norm.
I suggest setting the voltage here to be complete even if there are no
current users.
why wake-gpios? we should be using pinctrl with interrupt-extended to
do wakeup sequence, no?
sure, can you patch the edt driver ? I'll fix the DTS after that gets
merged
If you really want to go down that road, so you could probably help
review the pinctrl patches I posted to enable pinctrl wakeup[1]?
Come on, as of today, there is no ability to suspend AM437x without
doing [1], let alone talk about wakeup gpio vs interrupt-extended. and
do we really want to wakeup from suspend when touch screen is touched?
Do you expect wake-gpio to work even after doing interrupt based
solution? I am no edt driver expert... maybe you can help me here.
you missed the point entirely. This pin is not used for the touchscreen
to wake SoC up, it's the other way around, see how the pin is an
*output*. Pull it low and the touchscreen won't generate IRQs, won't
respond to i2c accesses, etc. Pull it high, and the thing wakes up.
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
--
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/20140618/06eacdea/attachment-0001.sig>
From: Felipe Balbi <hidden> Date: 2014-06-18 23:24:01
Hi,
(side note)
On Wed, Jun 18, 2014 at 06:19:23PM -0500, Felipe Balbi wrote:
quoted
quoted
quoted
quoted
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ dcdc1: regulator-dcdc1 {
+ compatible = "ti,tps65218-dcdc1";
+ /* VDD_CORE limits min of OPP50 and max of OPP100 */
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc2: regulator-dcdc2 {
+ compatible = "ti,tps65218-dcdc2";
+ /* VDD_MPU limits min of OPP50 and max of OPP_NITRO */
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1378000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3: regulator-dcdc3 {
+ compatible = "ti,tps65218-dcdc3";
+ regulator-name = "vdds_ddr";
no voltage ?
has no users in kernel. Also, it comes out with default, and correct,
voltage.
Device tree is description of hardware, not just who uses what in OS
of interest.
then we should start "fixing" every single DTS in the kernel because I'm
sure even LEDs and keypads are tied to some sort of supply, as is the
case with this board. No driver will use it though.
Also, I couldn't find anywhere which voltage is dcdc3 outputing and
there's no shunt anywhere (other than a 0 ohm resistor) to measure
voltage. So I kinda have my hands tied here.
(goes review schematics)
actually there's 0.05 ohm sense resistor. Hopefully it's easy to access.
why wake-gpios? we should be using pinctrl with interrupt-extended to
do wakeup sequence, no?
sure, can you patch the edt driver ? I'll fix the DTS after that gets
merged
If you really want to go down that road, so you could probably help
review the pinctrl patches I posted to enable pinctrl wakeup[1]?
Come on, as of today, there is no ability to suspend AM437x without
doing [1], let alone talk about wakeup gpio vs interrupt-extended. and
do we really want to wakeup from suspend when touch screen is touched?
Do you expect wake-gpio to work even after doing interrupt based
solution? I am no edt driver expert... maybe you can help me here.
you missed the point entirely. This pin is not used for the touchscreen
to wake SoC up, it's the other way around, see how the pin is an
*output*. Pull it low and the touchscreen won't generate IRQs, won't
respond to i2c accesses, etc. Pull it high, and the thing wakes up.
Aaah.. My apologies.. I was confused. Thanks for clarifying.
[...]
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.
--
Regards,
Nishanth Menon
why wake-gpios? we should be using pinctrl with interrupt-extended to
do wakeup sequence, no?
sure, can you patch the edt driver ? I'll fix the DTS after that gets
merged
If you really want to go down that road, so you could probably help
review the pinctrl patches I posted to enable pinctrl wakeup[1]?
Come on, as of today, there is no ability to suspend AM437x without
doing [1], let alone talk about wakeup gpio vs interrupt-extended. and
do we really want to wakeup from suspend when touch screen is touched?
Do you expect wake-gpio to work even after doing interrupt based
solution? I am no edt driver expert... maybe you can help me here.
you missed the point entirely. This pin is not used for the touchscreen
to wake SoC up, it's the other way around, see how the pin is an
*output*. Pull it low and the touchscreen won't generate IRQs, won't
respond to i2c accesses, etc. Pull it high, and the thing wakes up.
Aaah.. My apologies.. I was confused. Thanks for clarifying.
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.
--
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/20140618/afa0d569/attachment-0001.sig>
Hi,
On Wed, Jun 18, 2014 at 09:26:01PM -0500, Nishanth Menon wrote:
quoted
On 06/18/2014 06:19 PM, Felipe Balbi wrote:
[...]
quoted
quoted
quoted
quoted
quoted
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.
quoted
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).
[...]
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
From: Felipe Balbi <hidden> Date: 2014-06-19 04:03:09
Hi,
On Wed, Jun 18, 2014 at 10:17:34PM -0500, Nishanth Menon wrote:
On 06/18/2014 10:05 PM, Felipe Balbi wrote:
quoted
Hi,
On Wed, Jun 18, 2014 at 09:26:01PM -0500, Nishanth Menon wrote:
quoted
On 06/18/2014 06:19 PM, Felipe Balbi wrote:
[...]
quoted
quoted
quoted
quoted
quoted
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.
quoted
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.
dude, this is a Starter Kit after all. The probability of being sold
eventually is really, really high. I just can't confirm it certainly
will right now.
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).
I'll point you to schematics and internal wiki tomorrow if you want. I'm
sure there will be a public ti.com address for it though.
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.
if you ask me, it's just two extra instances of the fixed regulator
driver for a really marginal added benefit.
--
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/20140618/1d26bae3/attachment.sig>