Re: [PATCH 1/2] ARM: DRA7: hwmod: Add OCP2SCP3 module
On Wed, 18 Jun 2014, Roger Quadros wrote: > This module is needed for the SATA and PCIe PHYs. > > Signed-off-by: Roger Quadros > Tested-by: Roger Quadros Is this one a fix? It looks to me like a new IP block addition. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
Hi,
On Wed, Jun 18, 2014 at 10:17:34PM -0500, Nishanth Menon wrote:
> 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.
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.
> [...]
>
> >>> + 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@0 {
> > compatible = "regulator-fixed";
> > regulator-name = "V5_0D";
> > regulator-min-microvolt = <500>;
> > regulator-max-microvolt = <500>;
> > regulator-boot-on;
> > regulator-always-on;
> > vin-supply = <&dcdc4>;
> > };
> >
> > VBUS_USB: fixedregulator@1 {
> > compatible = "regulator-fixed";
> > regulator-name = "VBUS_USB";
> > regulator-min-microvolt = <500>;
> > regulator-max-microvolt = <500>;
> > 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
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
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@0 {
> compatible = "regulator-fixed";
> regulator-name = "V5_0D";
> regulator-min-microvolt = <500>;
> regulator-max-microvolt = <500>;
> regulator-boot-on;
> regulator-always-on;
> vin-supply = <&dcdc4>;
> };
>
> VBUS_USB: fixedregulator@1 {
> compatible = "regulator-fixed";
> regulator-name = "VBUS_USB";
> regulator-min-microvolt = <500>;
> regulator-max-microvolt = <500>;
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
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.
> >+edt-ft5306@38 {
> >+status = "okay";
> >+compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
> >+pinctrl-names = "default";
> >+pinctrl-0 = <&edt_ft5306_ts_pins>;
> >+reg = <0x38>;
> >+interrupt-parent = <&gpio0>;
> >+interrupts = <31 0>;
> >+
> >+wake-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
>
> 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.
np
> [...]
> >+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@0 {
compatible = "regulator-fixed";
regulator-name = "V5_0D";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-boot-on;
regulator-always-on;
vin-supply = <&dcdc4>;
};
VBUS_USB: fixedregulator@1 {
compatible = "regulator-fixed";
regulator-name = "VBUS_USB";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
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 w
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
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.
[...]
+ edt-ft5306@38 {
+ status = "okay";
+ compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
+ pinctrl-names = "default";
+ pinctrl-0 = <&edt_ft5306_ts_pins>;
+ reg = <0x38>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <31 0>;
+
+ wake-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
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.
[...]
+ 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.
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
Hi,
(side note)
On Wed, Jun 18, 2014 at 06:19:23PM -0500, Felipe Balbi wrote:
> > >>>+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.
1.35v
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
Hi,
On Wed, Jun 18, 2014 at 04:54:05PM -0500, Nishanth Menon wrote:
> On 06/18/2014 02:31 PM, Felipe Balbi wrote:
> >On Wed, Jun 18, 2014 at 11:14:21AM -0500, Nishanth Menon wrote:
> >>On 06/18/2014 10:43 AM, 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.
> [...]
> >>>+
> >>>+ matrix_keypad: matrix_keypad@0 {
> >>>+ compatible = "gpio-matrix-keypad";
> >>
> >>no pinctrl needed?
> >
> >pins are gpio by default
>
> 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.
> >>>+&i2c0 {
> >>>+status = "okay";
> >>>+pinctrl-names = "default";
> >>>+pinctrl-0 = <&i2c0_pins>;
> >>
> >>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.
> >>>+ 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.
>
> >>>+ edt-ft5306@38 {
> >>>+ status = "okay";
> >>>+ compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
> >>>+ pinctrl-names = "default";
> >>>+ pinctrl-0 = <&edt_ft5306_ts_pins>;
> >>>+ reg = <0x38>;
> >>>+ interrupt-parent = <&gpio0>;
> >>>+ interrupts = <31 0>;
> >>>+
> >>>+ wake-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
> >>
> >>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.
> >>>+&mmc1 {
> >>>+ status = "okay";
> >>>+ vmmc-supply = <&dcdc4>;
> >>>+ bus-width = <4>;
> >>>+ pinctrl-names = "default";
> >>>+ pinctrl-0 = <&mmc1_pins>;
> >>
> >
Re: [PATCH v2 1/2] arm: dts: am4372: let boards enable RTC and Watchdog
On 06/18/2014 04:51 PM, Felipe Balbi wrote:
Hi,
On Wed, Jun 18, 2014 at 04:43:28PM -0500, Nishanth Menon wrote:
On 06/18/2014 02:25 PM, Felipe Balbi wrote:
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:
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 49fa596..e3830d4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -270,7 +270,7 @@
ti,hwmods = "counter_32k";
};
- rtc@44e3e000 {
+ rtc: rtc@44e3e000 {
compatible = "ti,am4372-rtc","ti,da830-rtc";
reg = <0x44e3e000 0x1000>;
interrupts = ;
interrupts = ;
we might want to fix up any other similar nodes in dtsi as well, no?
examples:
cpu@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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
On 06/18/2014 02:31 PM, Felipe Balbi wrote:
On Wed, Jun 18, 2014 at 11:14:21AM -0500, Nishanth Menon wrote:
On 06/18/2014 10:43 AM, 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
internal only board.
[...]
+
+ matrix_keypad: matrix_keypad@0 {
+ compatible = "gpio-matrix-keypad";
no pinctrl needed?
pins are gpio by default
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.
[...]
+&i2c0 {
+status = "okay";
+pinctrl-names = "default";
+pinctrl-0 = <&i2c0_pins>;
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.
+ tps@24 {
+ compatible = "ti,tps65218";
+ reg = <0x24>;
+ interrupt-parent = <&gic>;
+ interrupts = ;
is this muxed?
there's no configuration for this. This pin is a single function.
+ 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.
+ edt-ft5306@38 {
+ status = "okay";
+ compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
+ pinctrl-names = "default";
+ pinctrl-0 = <&edt_ft5306_ts_pins>;
+ reg = <0x38>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <31 0>;
+
+ wake-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
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.
+&mmc1 {
+ status = "okay";
+ vmmc-supply = <&dcdc4>;
+ bus-width = <4>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc1_pins>;
just for style, wonder if moving the pinctrl just after status is better?
why ? makes no difference.
it does not - I agree, except, when you look at all other nodes:
status="okay"
pinctrl
other things..
it is just a symmetry thing, I guess..
+ 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.
[..]
[1] http://marc.info/?l=devicetree&m=140301966510748&w=2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordom
Re: [PATCH v2 1/2] arm: dts: am4372: let boards enable RTC and Watchdog
Hi,
On Wed, Jun 18, 2014 at 04:43:28PM -0500, Nishanth Menon wrote:
> On 06/18/2014 02:25 PM, Felipe Balbi wrote:
> >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:
> >>>by providing phandles to rtc and wdt nodes, we can
> >>>let boards enable rtc and wdt as necessary.
> >>>
> >>>Signed-off-by: Felipe Balbi
> >>>---
> >>> arch/arm/boot/dts/am4372.dtsi | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>>diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> >>>index 49fa596..e3830d4 100644
> >>>--- a/arch/arm/boot/dts/am4372.dtsi
> >>>+++ b/arch/arm/boot/dts/am4372.dtsi
> >>>@@ -270,7 +270,7 @@
> >>> ti,hwmods = "counter_32k";
> >>> };
> >>>
> >>>- rtc@44e3e000 {
> >>>+ rtc: rtc@44e3e000 {
> >>> compatible = "ti,am4372-rtc","ti,da830-rtc";
> >>> reg = <0x44e3e000 0x1000>;
> >>> interrupts = >>>@@ -279,7 +279,7 @@
> >>> status = "disabled";
> >>> };
> >>>
> >>>- wdt@44e35000 {
> >>>+ wdt: wdt@44e35000 {
> >>> compatible = "ti,am4372-wdt","ti,omap3-wdt";
> >>> reg = <0x44e35000 0x1000>;
> >>> interrupts = ;
> >>>
> >>we might want to fix up any other similar nodes in dtsi as well, no?
> >>
> >>examples:
> >>cpu@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?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2 1/2] arm: dts: am4372: let boards enable RTC and Watchdog
On 06/18/2014 02:25 PM, Felipe Balbi wrote:
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:
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 49fa596..e3830d4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -270,7 +270,7 @@
ti,hwmods = "counter_32k";
};
- rtc@44e3e000 {
+ rtc: rtc@44e3e000 {
compatible = "ti,am4372-rtc","ti,da830-rtc";
reg = <0x44e3e000 0x1000>;
interrupts = ;
interrupts = ;
we might want to fix up any other similar nodes in dtsi as well, no?
examples:
cpu@0
and why would you want boards to mess with the cpu node ?
cpu-supply = <®ulator>;
for cpufreq.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3-n900.dts: Rename model name to "Nokia RX-51 board"
Hi, On Wed, Jun 18, 2014 at 10:23:03PM +0200, Pali Rohár wrote: > On Wednesday 18 June 2014 22:12:41 Aaro Koskinen wrote: > > On Wed, Jun 18, 2014 at 06:57:15PM +0200, Pali Rohár wrote: > > > Use same name as in legacy board code. There are lot of > > > userspace applications which using machine/model name for > > > determinating device type. > > > > Can you clarify this? Nokia kernel or userspace never had DT, > > so they cannot see e.g. /proc/device-tree/model. What other > > APIs expose model? > > Basically that patch export model name in Hardware /proc/cpuinfo > instead generic DT name. And this patch change name to what > legacy board code reported. I don't like the idea of changing the model name from Nokia marketing names to those cryptic internal names in DT files. There also may be already some userspace relying to find current model name from /proc/device-tree/model (e.g. I think my own OS would break). A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3-n900.dts: Rename model name to "Nokia RX-51 board"
On Wednesday 18 June 2014 22:12:41 Aaro Koskinen wrote: > On Wed, Jun 18, 2014 at 06:57:15PM +0200, Pali Rohár wrote: > > Use same name as in legacy board code. There are lot of > > userspace applications which using machine/model name for > > determinating device type. > > Can you clarify this? Nokia kernel or userspace never had DT, > so they cannot see e.g. /proc/device-tree/model. What other > APIs expose model? > > A. Hi Aaro, look at email discussion about my previous patch with subject: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible Basically that patch export model name in Hardware /proc/cpuinfo instead generic DT name. And this patch change name to what legacy board code reported. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] omap3-n900.dts: Rename model name to "Nokia RX-51 board"
On Wed, Jun 18, 2014 at 06:57:15PM +0200, Pali Rohár wrote: > Use same name as in legacy board code. There are lot of userspace > applications which using machine/model name for determinating device type. Can you clarify this? Nokia kernel or userspace never had DT, so they cannot see e.g. /proc/device-tree/model. What other APIs expose model? A. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: DRA7: hwmod: Add OCP2SCP3 module
This module is needed for the SATA and PCIe PHYs.
Signed-off-by: Roger Quadros
Tested-by: Roger Quadros
---
v2:
- added .main_clk to hwmod.
- moved interface structure to the right place.
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..c9daee4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1215,6 +1215,21 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
},
};
+/* ocp2scp3 */
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
+ .name = "ocp2scp3",
+ .class = &dra7xx_ocp2scp_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .main_clk = "l4_root_clk_div",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'qspi' class
*
@@ -2326,6 +2341,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp1
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_cfg -> ocp2scp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_ocp2scp3_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_qspi_addrs[] = {
{
.pa_start = 0x4b30,
@@ -2672,6 +2695,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l4_per1__mmc4,
&dra7xx_l4_cfg__mpu,
&dra7xx_l4_cfg__ocp2scp1,
+ &dra7xx_l4_cfg__ocp2scp3,
&dra7xx_l3_main_1__qspi,
&dra7xx_l4_cfg__sata,
&dra7xx_l4_cfg__smartreflex_core,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: DRA7: hwmod: Add OCP2SCP3 module
On 06/18/2014 03:34 PM, Rajendra Nayak wrote:
> On Wednesday 18 June 2014 05:46 PM, Roger Quadros wrote:
>> This module is needed for the SATA and PCIe PHYs.
>>
>> Signed-off-by: Roger Quadros
>> Tested-by: Roger Quadros
>> ---
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 25 +
>> 1 file changed, 25 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 20b4398..cedef6b 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
>> },
>> };
>>
>> +/* ocp2scp3 */
>> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
>> +
>> +/* l4_cfg -> ocp2scp3 */
>> +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
>> +.master = &dra7xx_l4_cfg_hwmod,
>> +.slave = &dra7xx_ocp2scp3_hwmod,
>> +.clk= "l4_root_clk_div",
>> +.user = OCP_USER_MPU | OCP_USER_SDMA,
>> +};
>
> is it not possible to move this down in the file where all interface
> structs are defined?
yes, i'll send a v2 with this fixed as well as add .main_clk to the hwmod
like in ocp2scp1.
cheers,
-roger
>
>> +
>> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>> +.name = "ocp2scp3",
>> +.class = &dra7xx_ocp2scp_hwmod_class,
>> +.clkdm_name = "l3init_clkdm",
>> +.prcm = {
>> +.omap4 = {
>> +.clkctrl_offs =
>> DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
>> +.context_offs =
>> DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
>> +.modulemode = MODULEMODE_HWCTRL,
>> +},
>> +},
>> +};
>> +
>> /*
>> * 'qspi' class
>> *
>> @@ -2672,6 +2696,7 @@ static struct omap_hwmod_ocp_if
>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>> &dra7xx_l4_per1__mmc4,
>> &dra7xx_l4_cfg__mpu,
>> &dra7xx_l4_cfg__ocp2scp1,
>> +&dra7xx_l4_cfg__ocp2scp3,
>> &dra7xx_l3_main_1__qspi,
>> &dra7xx_l4_cfg__sata,
>> &dra7xx_l4_cfg__smartreflex_core,
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
On Wed, Jun 18, 2014 at 11:14:21AM -0500, Nishanth Menon wrote:
> On 06/18/2014 10:43 AM, Felipe Balbi wrote:
> > Add support for TI's AM437x StarterKit Evaluation
> > Module.
>
> is there a link for this platform?
internal only
> > Cc: Josh Elliot
> > Cc: Darren Etheridge
> > Signed-off-by: Felipe Balbi
> > ---
> > .../devicetree/bindings/arm/omap/omap.txt | 3 +
> > arch/arm/boot/dts/Makefile | 1 +
> > arch/arm/boot/dts/am437x-sk-evm.dts| 583
> > +
> > 3 files changed, 587 insertions(+)
> > create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
> >
> > diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> > b/Documentation/devicetree/bindings/arm/omap/omap.txt
> > index d22b216..0edc903 100644
> > --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> > +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> > @@ -129,6 +129,9 @@ Boards:
> > - AM437x GP EVM
> >compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
> >
> > +- AM437x SK EVM: AM437x StarterKit Evaluation Module
> > + compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
> > +
> > - DRA742 EVM: Software Development Board for DRA742
> >compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
> >
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 621c6c5..a85a4b8 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
> > omap4-var-dvk-om44.dtb \
> > omap4-var-stk-om44.dtb
> > dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
> > + am437x-sk-evm.dtb \
> > am437x-gp-evm.dtb
> > dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
> > omap5-sbc-t54.dtb \
> > diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
> > b/arch/arm/boot/dts/am437x-sk-evm.dts
> > new file mode 100644
> > index 000..e7a2bbe
> > --- /dev/null
> > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > @@ -0,0 +1,583 @@
> > +/*
> > + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +/* AM437x SK EVM */
> ??
> > +
> > +/dts-v1/;
> > +
> > +#include "am4372.dtsi"
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/ {
> > + model = "TI AM437x SK EVM";
> > + compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
> > +
> > + aliases {
> > + display0 = &lcd0;
> > + };
> > +
> > + backlight {
> > + compatible = "pwm-backlight";
> > + pwms = <&ecap0 0 5 PWM_POLARITY_INVERTED>;
> > + brightness-levels = <0 51 53 56 62 75 101 152 255>;
> > + default-brightness-level = <8>;
> > + };
> > +
> > + sound {
> > + compatible = "ti,da830-evm-audio";
> > + ti,model = "AM437x-SK-EVM";
> > + ti,audio-codec = <&tlv320aic3106>;
> > + ti,mcasp-controller = <&mcasp1>;
> > + ti,codec-clock-rate = <2400>;
> > + ti,audio-routing =
> > + "Headphone Jack", "HPLOUT",
> > + "Headphone Jack", "HPROUT";
> > + };
> > +
> > + matrix_keypad: matrix_keypad@0 {
> > + compatible = "gpio-matrix-keypad";
>
> no pinctrl needed?
pins are gpio by default
> > + debounce-delay-ms = <5>;
> > + col-scan-delay-us = <1500>;
> > +
> > + row-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH /* Bank5, pin5
> > */
> > + &gpio5 6 GPIO_ACTIVE_HIGH>; /* Bank5, pin6
> > */
> > +
> > + col-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH /* Bank5, pin13
> > */
> > + &gpio5 4 GPIO_ACTIVE_HIGH>; /* Bank5, pin4
> > */
> > +
> > + linux,keymap = <
> > + MATRIX_KEY(0, 0, KEY_DOWN)
> > + MATRIX_KEY(0, 1, KEY_RIGHT)
> > + MATRIX_KEY(1, 0, KEY_LEFT)
> > + MATRIX_KEY(1, 1, KEY_UP)
> > + >;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> no pinctrl needed?
likewise
> > + led@0 {
> > + label = "am437x-sk:red:heartbeat";
> > + gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
> > 0 */
> > + linux,default-trigger = "heartbeat";
> > + default-state = "off";
> > + };
> > +
> > + led@1 {
> > + label = "am437x-sk:green:mmc1";
> > + gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
> > 1 */
> > + linux,default-trigger = "mmc0";
> > + default-state = "off";
> > + };
> > +
> > +
Re: [PATCH v2 1/2] arm: dts: am4372: let boards enable RTC and Watchdog
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:
> > by providing phandles to rtc and wdt nodes, we can
> > let boards enable rtc and wdt as necessary.
> >
> > Signed-off-by: Felipe Balbi
> > ---
> > arch/arm/boot/dts/am4372.dtsi | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> > index 49fa596..e3830d4 100644
> > --- a/arch/arm/boot/dts/am4372.dtsi
> > +++ b/arch/arm/boot/dts/am4372.dtsi
> > @@ -270,7 +270,7 @@
> > ti,hwmods = "counter_32k";
> > };
> >
> > - rtc@44e3e000 {
> > + rtc: rtc@44e3e000 {
> > compatible = "ti,am4372-rtc","ti,da830-rtc";
> > reg = <0x44e3e000 0x1000>;
> > interrupts = > @@ -279,7 +279,7 @@
> > status = "disabled";
> > };
> >
> > - wdt@44e35000 {
> > + wdt: wdt@44e35000 {
> > compatible = "ti,am4372-wdt","ti,omap3-wdt";
> > reg = <0x44e35000 0x1000>;
> > interrupts = ;
> >
> we might want to fix up any other similar nodes in dtsi as well, no?
>
> examples:
> cpu@0
and why would you want boards to mess with the cpu node ?
> dispc@4832a400
perhaps
> Might also be nice to have Fixes: to point out which commit was being
> fixed, no?
no other board enables those, so I wouldn't consider it a fix.
--
balbi
signature.asc
Description: Digital signature
[PATCH] omap3-n900.dts: Rename model name to "Nokia RX-51 board"
Use same name as in legacy board code. There are lot of userspace applications
which using machine/model name for determinating device type. And changing this
name will break all of them. Due to small features support in DT code only non
DT kernel was used for Nokia N900 until now.
Signed-off-by: Pali Rohár
---
arch/arm/boot/dts/omap3-n900.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 6c6551a..e23ee96 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -13,7 +13,7 @@
#include
/ {
- model = "Nokia N900";
+ model = "Nokia RX-51 board";
compatible = "nokia,omap3-n900", "ti,omap3430", "ti,omap3";
aliases {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
On 06/18/2014 10:43 AM, Felipe Balbi wrote:
> Add support for TI's AM437x StarterKit Evaluation
> Module.
is there a link for this platform?
>
> Cc: Josh Elliot
> Cc: Darren Etheridge
> Signed-off-by: Felipe Balbi
> ---
> .../devicetree/bindings/arm/omap/omap.txt | 3 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am437x-sk-evm.dts| 583
> +
> 3 files changed, 587 insertions(+)
> create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
> b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index d22b216..0edc903 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -129,6 +129,9 @@ Boards:
> - AM437x GP EVM
>compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
>
> +- AM437x SK EVM: AM437x StarterKit Evaluation Module
> + compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
> +
> - DRA742 EVM: Software Development Board for DRA742
>compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 621c6c5..a85a4b8 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
> omap4-var-dvk-om44.dtb \
> omap4-var-stk-om44.dtb
> dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
> + am437x-sk-evm.dtb \
> am437x-gp-evm.dtb
> dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
> omap5-sbc-t54.dtb \
> diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
> b/arch/arm/boot/dts/am437x-sk-evm.dts
> new file mode 100644
> index 000..e7a2bbe
> --- /dev/null
> +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> @@ -0,0 +1,583 @@
> +/*
> + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/* AM437x SK EVM */
??
> +
> +/dts-v1/;
> +
> +#include "am4372.dtsi"
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + model = "TI AM437x SK EVM";
> + compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
> +
> + aliases {
> + display0 = &lcd0;
> + };
> +
> + backlight {
> + compatible = "pwm-backlight";
> + pwms = <&ecap0 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 51 53 56 62 75 101 152 255>;
> + default-brightness-level = <8>;
> + };
> +
> + sound {
> + compatible = "ti,da830-evm-audio";
> + ti,model = "AM437x-SK-EVM";
> + ti,audio-codec = <&tlv320aic3106>;
> + ti,mcasp-controller = <&mcasp1>;
> + ti,codec-clock-rate = <2400>;
> + ti,audio-routing =
> + "Headphone Jack", "HPLOUT",
> + "Headphone Jack", "HPROUT";
> + };
> +
> + matrix_keypad: matrix_keypad@0 {
> + compatible = "gpio-matrix-keypad";
no pinctrl needed?
> +
> + debounce-delay-ms = <5>;
> + col-scan-delay-us = <1500>;
> +
> + row-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH /* Bank5, pin5
> */
> + &gpio5 6 GPIO_ACTIVE_HIGH>; /* Bank5, pin6
> */
> +
> + col-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH /* Bank5, pin13
> */
> + &gpio5 4 GPIO_ACTIVE_HIGH>; /* Bank5, pin4
> */
> +
> + linux,keymap = <
> + MATRIX_KEY(0, 0, KEY_DOWN)
> + MATRIX_KEY(0, 1, KEY_RIGHT)
> + MATRIX_KEY(1, 0, KEY_LEFT)
> + MATRIX_KEY(1, 1, KEY_UP)
> + >;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
no pinctrl needed?
> +
> + led@0 {
> + label = "am437x-sk:red:heartbeat";
> + gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
> 0 */
> + linux,default-trigger = "heartbeat";
> + default-state = "off";
> + };
> +
> + led@1 {
> + label = "am437x-sk:green:mmc1";
> + gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
> 1 */
> + linux,default-trigger = "mmc0";
> + default-state = "off";
> + };
> +
> + led@2 {
> + label = "am437x-sk:blue:cpu0";
> + gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
> 2 */
> + linux,default-trigger = "cpu0";
> + default-state = "off";
> +
Re: [PATCH v2 1/2] arm: dts: am4372: let boards enable RTC and Watchdog
$subject - ARM: dts:
On 06/18/2014 10:43 AM, Felipe Balbi wrote:
> by providing phandles to rtc and wdt nodes, we can
> let boards enable rtc and wdt as necessary.
>
> Signed-off-by: Felipe Balbi
> ---
> arch/arm/boot/dts/am4372.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index 49fa596..e3830d4 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -270,7 +270,7 @@
> ti,hwmods = "counter_32k";
> };
>
> - rtc@44e3e000 {
> + rtc: rtc@44e3e000 {
> compatible = "ti,am4372-rtc","ti,da830-rtc";
> reg = <0x44e3e000 0x1000>;
> interrupts = @@ -279,7 +279,7 @@
> status = "disabled";
> };
>
> - wdt@44e35000 {
> + wdt: wdt@44e35000 {
> compatible = "ti,am4372-wdt","ti,omap3-wdt";
> reg = <0x44e35000 0x1000>;
> interrupts = ;
>
we might want to fix up any other similar nodes in dtsi as well, no?
examples:
cpu@0
dispc@4832a400
Might also be nice to have Fixes: to point out which commit was being
fixed, no?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulators: TPS65218: Add the missing of_node assignment in probe
nit pick:
s/regulators: TPS65218:/regulators: tps65218:/
On 06/18/2014 10:17 AM, Felipe Balbi wrote:
> From: Keerthy
>
> Add the missing of_node assignment in probe.
Hmm... I think an explanation of the type below might be nice:
config.of_node is used to populate the regulator_dev->dev.of_node as
part of registration. this is used for consumer supply match to the
right regulator device such as in regulator_dev_lookup.
not populating config.of_node results in inability to use the
regulator node as a supply in device tree.
>
> Cc: # v3.15
Fixes: 90e7d5262796 (regulator: tps65218: Add Regulator driver for
TPS65218 PMIC)
?
> Signed-off-by: Keerthy
> Signed-off-by: Felipe Balbi
> ---
> drivers/regulator/tps65218-regulator.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/regulator/tps65218-regulator.c
> b/drivers/regulator/tps65218-regulator.c
> index 69b4b77..edbc46e 100644
> --- a/drivers/regulator/tps65218-regulator.c
> +++ b/drivers/regulator/tps65218-regulator.c
> @@ -240,6 +240,7 @@ static int tps65218_regulator_probe(struct
> platform_device *pdev)
> config.init_data = init_data;
> config.driver_data = tps;
> config.regmap = tps->regmap;
> + config.of_node = pdev->dev.of_node;
>
> rdev = devm_regulator_register(&pdev->dev, ®ulators[id], &config);
> if (IS_ERR(rdev)) {
>
otherwise,
Acked-by: Nishanth Menon
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] arm: dts: add support for am437x sk
Hi, here's v2 of am437x sk support. Patches tested on top of next-20140617. Note that this series was tested with the following extra patches: http://marc.info/?l=linux-omap&m=140299431732700&w=2 http://marc.info/?l=linux-omap&m=140300146503126&w=2 http://marc.info/?l=linux-omap&m=140299231232123 http://marc.info/?l=linux-omap&m=140310472709968&w=2 http://marc.info/?l=linux-omap&m=140310471409959&w=2 A branch is also available with all these patches at [1] and serial console capture is available at [2]. [1] http://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=am437x-starterkit [2] http://slexy.org/view/s20wyUDXDh Felipe Balbi (2): arm: dts: am4372: let boards enable RTC and Watchdog arm: dts: add support for AM437x StarterKit .../devicetree/bindings/arm/omap/omap.txt | 3 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/am4372.dtsi | 4 +- arch/arm/boot/dts/am437x-sk-evm.dts| 583 + 4 files changed, 589 insertions(+), 2 deletions(-) create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts -- 2.0.0.rc1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] arm: dts: add support for AM437x StarterKit
Add support for TI's AM437x StarterKit Evaluation
Module.
Cc: Josh Elliot
Cc: Darren Etheridge
Signed-off-by: Felipe Balbi
---
.../devicetree/bindings/arm/omap/omap.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/am437x-sk-evm.dts| 583 +
3 files changed, 587 insertions(+)
create mode 100644 arch/arm/boot/dts/am437x-sk-evm.dts
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt
b/Documentation/devicetree/bindings/arm/omap/omap.txt
index d22b216..0edc903 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -129,6 +129,9 @@ Boards:
- AM437x GP EVM
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
+- AM437x SK EVM: AM437x StarterKit Evaluation Module
+ compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
+
- DRA742 EVM: Software Development Board for DRA742
compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 621c6c5..a85a4b8 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -306,6 +306,7 @@ dtb-$(CONFIG_ARCH_OMAP4) += omap4-duovero-parlor.dtb \
omap4-var-dvk-om44.dtb \
omap4-var-stk-om44.dtb
dtb-$(CONFIG_SOC_AM43XX) += am43x-epos-evm.dtb \
+ am437x-sk-evm.dtb \
am437x-gp-evm.dtb
dtb-$(CONFIG_SOC_OMAP5) += omap5-cm-t54.dtb \
omap5-sbc-t54.dtb \
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
new file mode 100644
index 000..e7a2bbe
--- /dev/null
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -0,0 +1,583 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* AM437x SK EVM */
+
+/dts-v1/;
+
+#include "am4372.dtsi"
+#include
+#include
+#include
+#include
+
+/ {
+ model = "TI AM437x SK EVM";
+ compatible = "ti,am437x-sk-evm","ti,am4372","ti,am43";
+
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&ecap0 0 5 PWM_POLARITY_INVERTED>;
+ brightness-levels = <0 51 53 56 62 75 101 152 255>;
+ default-brightness-level = <8>;
+ };
+
+ sound {
+ compatible = "ti,da830-evm-audio";
+ ti,model = "AM437x-SK-EVM";
+ ti,audio-codec = <&tlv320aic3106>;
+ ti,mcasp-controller = <&mcasp1>;
+ ti,codec-clock-rate = <2400>;
+ ti,audio-routing =
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT";
+ };
+
+ matrix_keypad: matrix_keypad@0 {
+ compatible = "gpio-matrix-keypad";
+
+ debounce-delay-ms = <5>;
+ col-scan-delay-us = <1500>;
+
+ row-gpios = <&gpio5 5 GPIO_ACTIVE_HIGH /* Bank5, pin5
*/
+ &gpio5 6 GPIO_ACTIVE_HIGH>; /* Bank5, pin6
*/
+
+ col-gpios = <&gpio5 13 GPIO_ACTIVE_HIGH /* Bank5, pin13
*/
+ &gpio5 4 GPIO_ACTIVE_HIGH>; /* Bank5, pin4
*/
+
+ linux,keymap = <
+ MATRIX_KEY(0, 0, KEY_DOWN)
+ MATRIX_KEY(0, 1, KEY_RIGHT)
+ MATRIX_KEY(1, 0, KEY_LEFT)
+ MATRIX_KEY(1, 1, KEY_UP)
+ >;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led@0 {
+ label = "am437x-sk:red:heartbeat";
+ gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
0 */
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ led@1 {
+ label = "am437x-sk:green:mmc1";
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
1 */
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led@2 {
+ label = "am437x-sk:blue:cpu0";
+ gpios = <&gpio5 2 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
2 */
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+
+ led@3 {
+ label = "am437x-sk:blue:usr3";
+ gpios = <&gpio5 3 GPIO_ACTIVE_HIGH>;/* Bank 5, pin
3 */
+ default-state = "off";
+ };
+ };
+
+ lcd0: display {
+
[PATCH v2 1/2] arm: dts: am4372: let boards enable RTC and Watchdog
by providing phandles to rtc and wdt nodes, we can
let boards enable rtc and wdt as necessary.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am4372.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 49fa596..e3830d4 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -270,7 +270,7 @@
ti,hwmods = "counter_32k";
};
- rtc@44e3e000 {
+ rtc: rtc@44e3e000 {
compatible = "ti,am4372-rtc","ti,da830-rtc";
reg = <0x44e3e000 0x1000>;
interrupts = ;
interrupts = ;
--
2.0.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] regulators: TPS65218: Correct the the config register for LDO1
nit pick:
s/regulators: TPS65218:/regulators: tps65218:/
On 06/18/2014 10:17 AM, Felipe Balbi wrote:
> From: Keerthy
>
> Correct the the config register for LDO1.
>
> Cc: # v3.15
Fixes: 90e7d5262796 (regulator: tps65218: Add Regulator driver for
TPS65218 PMIC)
?
> Signed-off-by: Keerthy
> Signed-off-by: Felipe Balbi
> ---
> drivers/regulator/tps65218-regulator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/tps65218-regulator.c
> b/drivers/regulator/tps65218-regulator.c
> index edbc46e..9effe48 100644
> --- a/drivers/regulator/tps65218-regulator.c
> +++ b/drivers/regulator/tps65218-regulator.c
> @@ -209,7 +209,7 @@ static const struct regulator_desc regulators[] = {
> 1, -1, -1, TPS65218_REG_ENABLE1,
> TPS65218_ENABLE1_DC6_EN, NULL, NULL, 0, 0),
> TPS65218_REGULATOR("LDO1", TPS65218_LDO_1, tps65218_ldo1_dcdc34_ops, 64,
> -TPS65218_REG_CONTROL_DCDC4,
> +TPS65218_REG_CONTROL_LDO1,
> TPS65218_CONTROL_LDO1_MASK, TPS65218_REG_ENABLE2,
> TPS65218_ENABLE2_LDO1_EN, NULL, ldo1_dcdc3_ranges,
> 2, 0),
>
otherwise,
Acked-by: Nishanth Menon
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] regulators: TPS65218: Add the missing of_node assignment in probe
From: Keerthy
Add the missing of_node assignment in probe.
Cc: # v3.15
Signed-off-by: Keerthy
Signed-off-by: Felipe Balbi
---
drivers/regulator/tps65218-regulator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index 69b4b77..edbc46e 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -240,6 +240,7 @@ static int tps65218_regulator_probe(struct platform_device
*pdev)
config.init_data = init_data;
config.driver_data = tps;
config.regmap = tps->regmap;
+ config.of_node = pdev->dev.of_node;
rdev = devm_regulator_register(&pdev->dev, ®ulators[id], &config);
if (IS_ERR(rdev)) {
--
2.0.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] regulators: TPS65218: Correct the the config register for LDO1
From: Keerthy
Correct the the config register for LDO1.
Cc: # v3.15
Signed-off-by: Keerthy
Signed-off-by: Felipe Balbi
---
drivers/regulator/tps65218-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/tps65218-regulator.c
b/drivers/regulator/tps65218-regulator.c
index edbc46e..9effe48 100644
--- a/drivers/regulator/tps65218-regulator.c
+++ b/drivers/regulator/tps65218-regulator.c
@@ -209,7 +209,7 @@ static const struct regulator_desc regulators[] = {
1, -1, -1, TPS65218_REG_ENABLE1,
TPS65218_ENABLE1_DC6_EN, NULL, NULL, 0, 0),
TPS65218_REGULATOR("LDO1", TPS65218_LDO_1, tps65218_ldo1_dcdc34_ops, 64,
- TPS65218_REG_CONTROL_DCDC4,
+ TPS65218_REG_CONTROL_LDO1,
TPS65218_CONTROL_LDO1_MASK, TPS65218_REG_ENABLE2,
TPS65218_ENABLE2_LDO1_EN, NULL, ldo1_dcdc3_ranges,
2, 0),
--
2.0.0.rc1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: DRA7: hwmod: Add OCP2SCP3 module
On Wednesday 18 June 2014 05:46 PM, Roger Quadros wrote:
> This module is needed for the SATA and PCIe PHYs.
>
> Signed-off-by: Roger Quadros
> Tested-by: Roger Quadros
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 20b4398..cedef6b 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
> },
> };
>
> +/* ocp2scp3 */
> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
> +
> +/* l4_cfg -> ocp2scp3 */
> +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
> + .master = &dra7xx_l4_cfg_hwmod,
> + .slave = &dra7xx_ocp2scp3_hwmod,
> + .clk= "l4_root_clk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
is it not possible to move this down in the file where all interface
structs are defined?
> +
> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
> + .name = "ocp2scp3",
> + .class = &dra7xx_ocp2scp_hwmod_class,
> + .clkdm_name = "l3init_clkdm",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs =
> DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
> + .context_offs =
> DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
> + },
> + },
> +};
> +
> /*
> * 'qspi' class
> *
> @@ -2672,6 +2696,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
> __initdata = {
> &dra7xx_l4_per1__mmc4,
> &dra7xx_l4_cfg__mpu,
> &dra7xx_l4_cfg__ocp2scp1,
> + &dra7xx_l4_cfg__ocp2scp3,
> &dra7xx_l3_main_1__qspi,
> &dra7xx_l4_cfg__sata,
> &dra7xx_l4_cfg__smartreflex_core,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: DRA7: hwmod: Add OCP2SCP3 module
This module is needed for the SATA and PCIe PHYs.
Signed-off-by: Roger Quadros
Tested-by: Roger Quadros
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 20b4398..cedef6b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
},
};
+/* ocp2scp3 */
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
+
+/* l4_cfg -> ocp2scp3 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
+ .master = &dra7xx_l4_cfg_hwmod,
+ .slave = &dra7xx_ocp2scp3_hwmod,
+ .clk= "l4_root_clk_div",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
+ .name = "ocp2scp3",
+ .class = &dra7xx_ocp2scp_hwmod_class,
+ .clkdm_name = "l3init_clkdm",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_HWCTRL,
+ },
+ },
+};
+
/*
* 'qspi' class
*
@@ -2672,6 +2696,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
&dra7xx_l4_per1__mmc4,
&dra7xx_l4_cfg__mpu,
&dra7xx_l4_cfg__ocp2scp1,
+ &dra7xx_l4_cfg__ocp2scp3,
&dra7xx_l3_main_1__qspi,
&dra7xx_l4_cfg__sata,
&dra7xx_l4_cfg__smartreflex_core,
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: DRA7: hwmod: Fixup SATA hwmod
Get rid of optional clock as that is now managed by the
AHCI platform driver.
Correct .mpu_rt_idx to 1 as the module register space (SYSCONFIG..)
is passed as the second memory resource in the device tree.
Signed-off-by: Roger Quadros
Tested-by: Roger Quadros
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index cedef6b..bc42eab 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1292,9 +1292,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class = {
};
/* sata */
-static struct omap_hwmod_opt_clk sata_opt_clks[] = {
- { .role = "ref_clk", .clk = "sata_ref_clk" },
-};
static struct omap_hwmod dra7xx_sata_hwmod = {
.name = "sata",
@@ -1302,6 +1299,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.clkdm_name = "l3init_clkdm",
.flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
.main_clk = "func_48m_fclk",
+ .mpu_rt_idx = 1,
.prcm = {
.omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
@@ -1309,8 +1307,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
.modulemode = MODULEMODE_SWCTRL,
},
},
- .opt_clks = sata_opt_clks,
- .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
};
/*
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: DRA7: hwmod: fixes for 3.16
Hi, These patches add the missing OCP2SCP3 module and fixup the SATA hwmod for DRA7 SoC. Both patches are tested on 3.16-rc1. SATA should have worked on DRA7-evm with just these 2 patches on top of 3.16-rc1,but it didn't :(. So something else is missing and needs to be investigated. SATA worked fine on omap5-uevm though so the problem is DRA7 specific. The patches are required for 3.16 in any case. cheers, -roger Roger Quadros (2): ARM: DRA7: hwmod: Add OCP2SCP3 module ARM: DRA7: hwmod: Fixup SATA hwmod arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31 ++- 1 file changed, 26 insertions(+), 5 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
On 06/18/2014 02:19 PM, Rajendra Nayak wrote:
> On Wednesday 18 June 2014 04:40 PM, Roger Quadros wrote:
>> + Nishant and Rajendra for review.
>>
>> On 05/05/2014 12:54 PM, Roger Quadros wrote:
>>> Add the sysconfig class bits for the Super Speed USB
>>> controllers
>>>
>>> CC: Paul Walmsley
>>> Signed-off-by: Roger Quadros
>
> verified against TRM version vP, looks good to me.
> Reviewed-by: Rajendra Nayak
Tested-by: Roger Quadros
against 3.16-rc1. no dependency patches.
cheers,
-roger
>
>>> ---
>>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 12
>>> 1 file changed, 12 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> index 810c205..067d322 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> @@ -1731,8 +1731,20 @@ static struct omap_hwmod dra7xx_uart6_hwmod = {
>>> *
>>> */
>>>
>>> +static struct omap_hwmod_class_sysconfig dra7xx_usb_otg_ss_sysc = {
>>> + .rev_offs = 0x,
>>> + .sysc_offs = 0x0010,
>>> + .sysc_flags = (SYSC_HAS_DMADISABLE | SYSC_HAS_MIDLEMODE |
>>> + SYSC_HAS_SIDLEMODE),
>>> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>>> + SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
>>> + MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
>>> + .sysc_fields= &omap_hwmod_sysc_type2,
>>> +};
>>> +
>>> static struct omap_hwmod_class dra7xx_usb_otg_ss_hwmod_class = {
>>> .name = "usb_otg_ss",
>>> + .sysc = &dra7xx_usb_otg_ss_sysc,
>>> };
>>>
>>> /* usb_otg_ss1 */
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
On Wednesday 18 June 2014 04:40 PM, Roger Quadros wrote:
> + Nishant and Rajendra for review.
>
> On 05/05/2014 12:54 PM, Roger Quadros wrote:
>> Add the sysconfig class bits for the Super Speed USB
>> controllers
>>
>> CC: Paul Walmsley
>> Signed-off-by: Roger Quadros
verified against TRM version vP, looks good to me.
Reviewed-by: Rajendra Nayak
>> ---
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 12
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 810c205..067d322 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -1731,8 +1731,20 @@ static struct omap_hwmod dra7xx_uart6_hwmod = {
>> *
>> */
>>
>> +static struct omap_hwmod_class_sysconfig dra7xx_usb_otg_ss_sysc = {
>> +.rev_offs = 0x,
>> +.sysc_offs = 0x0010,
>> +.sysc_flags = (SYSC_HAS_DMADISABLE | SYSC_HAS_MIDLEMODE |
>> + SYSC_HAS_SIDLEMODE),
>> +.idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>> + SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
>> + MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
>> +.sysc_fields= &omap_hwmod_sysc_type2,
>> +};
>> +
>> static struct omap_hwmod_class dra7xx_usb_otg_ss_hwmod_class = {
>> .name = "usb_otg_ss",
>> +.sysc = &dra7xx_usb_otg_ss_sysc,
>> };
>>
>> /* usb_otg_ss1 */
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
On 06/18/2014 01:29 PM, Rajendra Nayak wrote:
> On Wednesday 18 June 2014 01:32 PM, Roger Quadros wrote:
>> On 04/23/2014 08:35 PM, Roger Quadros wrote:
>>> From: Nikhil Devshatwar
>>>
>>> Add hwmods for ocp2scp3 and sata modules.
>
> From what I see this is actually adding the ocp2scp3 data and fixing up some
> of the sata data which is already added and erroneous.
>
> It would help if this is split up and the changelog explains whats fixed up
> for
> sata and why. Like for instance I see the opt clock data being removed but no
> mention of why.
OK. I will split this up into 2 patches, one to add ocp2scp3 data and the other
to fix sata hwmod.
cheers,
-roger
>
>>>
>>> [Roger Q] Clean up.
>>>
>>> CC: Benoit Cousson
>>> CC: Paul Walmsley
>>> Signed-off-by: Balaji T K
>>> Signed-off-by: Nikhil Devshatwar
>>> Signed-off-by: Roger Quadros
>>
>> Tested-by: Roger Quadros
>> against 3.16-rc1, no dependency patches needed.
>>
>> Nishant/Rajendra,
>>
>> Could you please review this? We need this for 3.16 SATA support and
>> Paul won't take this in without your reviewed-by tag. Thanks.
>>
>> cheers,
>> -roger
>>
>>> ---
>>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31
>>> ++-
>>> 1 file changed, 26 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> index 810c205..b02a4ab 100644
>>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>>> @@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
>>> },
>>> };
>>>
>>> +/* ocp2scp3 */
>>> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
>>> +
>>> +/* l4_cfg -> ocp2scp3 */
>>> +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
>>> + .master = &dra7xx_l4_cfg_hwmod,
>>> + .slave = &dra7xx_ocp2scp3_hwmod,
>>> + .clk= "l4_root_clk_div",
>>> + .user = OCP_USER_MPU | OCP_USER_SDMA,
>>> +};
>
> All hwmod data files are organized in a certain way with all the hwmod/IP
> block info on top
> and Interface structs at the bottom. Can we follow the same for ocp2scp3? It
> helps with better
> readability.
>
>>> +
>>> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>>> + .name = "ocp2scp3",
>>> + .class = &dra7xx_ocp2scp_hwmod_class,
>>> + .clkdm_name = "l3init_clkdm",
>
> No main_clk?
>
> regards,
> Rajendra
>
>>> + .prcm = {
>>> + .omap4 = {
>>> + .clkctrl_offs =
>>> DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
>>> + .context_offs =
>>> DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
>>> + .modulemode = MODULEMODE_HWCTRL,
>>> + },
>>> + },
>>> +};
>>> +
>>> /*
>>> * 'qspi' class
>>> *
>>> @@ -1268,9 +1292,6 @@ static struct omap_hwmod_class
>>> dra7xx_sata_hwmod_class = {
>>> };
>>>
>>> /* sata */
>>> -static struct omap_hwmod_opt_clk sata_opt_clks[] = {
>>> - { .role = "ref_clk", .clk = "sata_ref_clk" },
>>> -};
>>>
>>> static struct omap_hwmod dra7xx_sata_hwmod = {
>>> .name = "sata",
>>> @@ -1278,6 +1299,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
>>> .clkdm_name = "l3init_clkdm",
>>> .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
>>> .main_clk = "func_48m_fclk",
>>> + .mpu_rt_idx = 1,
>>> .prcm = {
>>> .omap4 = {
>>> .clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
>>> @@ -1285,8 +1307,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
>>> .modulemode = MODULEMODE_SWCTRL,
>>> },
>>> },
>>> - .opt_clks = sata_opt_clks,
>>> - .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
>>> };
>>>
>>> /*
>>> @@ -2682,6 +2702,7 @@ static struct omap_hwmod_ocp_if
>>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>>> &dra7xx_l4_per1__mmc4,
>>> &dra7xx_l4_cfg__mpu,
>>> &dra7xx_l4_cfg__ocp2scp1,
>>> + &dra7xx_l4_cfg__ocp2scp3,
>>> &dra7xx_l3_main_1__qspi,
>>> &dra7xx_l4_cfg__sata,
>>> &dra7xx_l4_cfg__smartreflex_core,
>>>
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/7] ARM: DRA7: hwmod: Add SYSCONFIG for usb_otg_ss
+ Nishant and Rajendra for review.
On 05/05/2014 12:54 PM, Roger Quadros wrote:
> Add the sysconfig class bits for the Super Speed USB
> controllers
>
> CC: Paul Walmsley
> Signed-off-by: Roger Quadros
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 810c205..067d322 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1731,8 +1731,20 @@ static struct omap_hwmod dra7xx_uart6_hwmod = {
> *
> */
>
> +static struct omap_hwmod_class_sysconfig dra7xx_usb_otg_ss_sysc = {
> + .rev_offs = 0x,
> + .sysc_offs = 0x0010,
> + .sysc_flags = (SYSC_HAS_DMADISABLE | SYSC_HAS_MIDLEMODE |
> +SYSC_HAS_SIDLEMODE),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
> +MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> + .sysc_fields= &omap_hwmod_sysc_type2,
> +};
> +
> static struct omap_hwmod_class dra7xx_usb_otg_ss_hwmod_class = {
> .name = "usb_otg_ss",
> + .sysc = &dra7xx_usb_otg_ss_sysc,
> };
>
> /* usb_otg_ss1 */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
On Wednesday 18 June 2014 01:32 PM, Roger Quadros wrote:
> On 04/23/2014 08:35 PM, Roger Quadros wrote:
>> From: Nikhil Devshatwar
>>
>> Add hwmods for ocp2scp3 and sata modules.
>From what I see this is actually adding the ocp2scp3 data and fixing up some
of the sata data which is already added and erroneous.
It would help if this is split up and the changelog explains whats fixed up for
sata and why. Like for instance I see the opt clock data being removed but no
mention of why.
>>
>> [Roger Q] Clean up.
>>
>> CC: Benoit Cousson
>> CC: Paul Walmsley
>> Signed-off-by: Balaji T K
>> Signed-off-by: Nikhil Devshatwar
>> Signed-off-by: Roger Quadros
>
> Tested-by: Roger Quadros
> against 3.16-rc1, no dependency patches needed.
>
> Nishant/Rajendra,
>
> Could you please review this? We need this for 3.16 SATA support and
> Paul won't take this in without your reviewed-by tag. Thanks.
>
> cheers,
> -roger
>
>> ---
>> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31
>> ++-
>> 1 file changed, 26 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> index 810c205..b02a4ab 100644
>> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
>> @@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
>> },
>> };
>>
>> +/* ocp2scp3 */
>> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
>> +
>> +/* l4_cfg -> ocp2scp3 */
>> +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
>> +.master = &dra7xx_l4_cfg_hwmod,
>> +.slave = &dra7xx_ocp2scp3_hwmod,
>> +.clk= "l4_root_clk_div",
>> +.user = OCP_USER_MPU | OCP_USER_SDMA,
>> +};
All hwmod data files are organized in a certain way with all the hwmod/IP block
info on top
and Interface structs at the bottom. Can we follow the same for ocp2scp3? It
helps with better
readability.
>> +
>> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
>> +.name = "ocp2scp3",
>> +.class = &dra7xx_ocp2scp_hwmod_class,
>> +.clkdm_name = "l3init_clkdm",
No main_clk?
regards,
Rajendra
>> +.prcm = {
>> +.omap4 = {
>> +.clkctrl_offs =
>> DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
>> +.context_offs =
>> DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
>> +.modulemode = MODULEMODE_HWCTRL,
>> +},
>> +},
>> +};
>> +
>> /*
>> * 'qspi' class
>> *
>> @@ -1268,9 +1292,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class
>> = {
>> };
>>
>> /* sata */
>> -static struct omap_hwmod_opt_clk sata_opt_clks[] = {
>> -{ .role = "ref_clk", .clk = "sata_ref_clk" },
>> -};
>>
>> static struct omap_hwmod dra7xx_sata_hwmod = {
>> .name = "sata",
>> @@ -1278,6 +1299,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
>> .clkdm_name = "l3init_clkdm",
>> .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
>> .main_clk = "func_48m_fclk",
>> +.mpu_rt_idx = 1,
>> .prcm = {
>> .omap4 = {
>> .clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
>> @@ -1285,8 +1307,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
>> .modulemode = MODULEMODE_SWCTRL,
>> },
>> },
>> -.opt_clks = sata_opt_clks,
>> -.opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
>> };
>>
>> /*
>> @@ -2682,6 +2702,7 @@ static struct omap_hwmod_ocp_if
>> *dra7xx_hwmod_ocp_ifs[] __initdata = {
>> &dra7xx_l4_per1__mmc4,
>> &dra7xx_l4_cfg__mpu,
>> &dra7xx_l4_cfg__ocp2scp1,
>> +&dra7xx_l4_cfg__ocp2scp3,
>> &dra7xx_l3_main_1__qspi,
>> &dra7xx_l4_cfg__sata,
>> &dra7xx_l4_cfg__smartreflex_core,
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/9] regulator: palmas: Add tps65917 compatible string
Add tps65917 compatible string. Signed-off-by: Keerthy --- .../devicetree/bindings/regulator/palmas-pmic.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt index 42e6b6b..725393c 100644 --- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt +++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt @@ -7,6 +7,7 @@ Required properties: ti,twl6037-pmic ti,tps65913-pmic ti,tps65914-pmic + ti,tps65917-pmic and also the generic series names ti,palmas-pmic - interrupt-parent : The parent interrupt controller which is palmas. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/9] mfd: tps65917: Add support for for TPS65917 PMIC
The TPS65917 chip is a power management IC for Portable Navigation Systems and Tablet Computing devices. It contains the following components: - Regulators. - GPADC. - Over Temperature warning and Shut down. This patch series adds support for TPS65917 mfd device. At this time only the regulator functionality is made available. The closest drivers are PALMAS series drivers. Hence adapted palmas mfd driver to support the tps65917 PMIC. The register set for SMPSs and LDOs are changed and the ramp delay support is also changed. Bit-field defenitions are changed. Hence added driver data structures for mfd and regulator drivers for palmas and added support for tps65917. The patches are boot tested on DRA72-EVM. The patches are boot tested on OMAP5-UEVM board. Keerthy (9): mfd: Add DT bindings for tps65917 PMIC regulator: palmas: Add tps65917 compatible string mfd: palmas: Add tps65917 specific definitions and enums mfd: palmas: Add tps65917 support regulator: palmas: Shift the reg_info structure definition to the header file mfd: palmas: shift the palmas_sleep_requestor_info structure definition to the header file regulator: palmas: Add palmas_pmic_driver_data structure regulator: palmas: add driver data and modularize the probe regulator: palmas: Add tps65917 PMIC support Documentation/devicetree/bindings/mfd/palmas.txt |2 + .../devicetree/bindings/regulator/palmas-pmic.txt |1 + drivers/mfd/palmas.c | 233 +++-- drivers/regulator/palmas-regulator.c | 1010 +++- include/linux/mfd/palmas.h | 837 5 files changed, 1774 insertions(+), 309 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/9] mfd: palmas: Add tps65917 specific definitions and enums
Add tps65917 specific definitions and enums.
Acked-by: Lee Jones
Signed-off-by: Keerthy
---
include/linux/mfd/palmas.h | 793
1 file changed, 793 insertions(+)
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 3420e09..f760a07 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -30,6 +30,8 @@
#define PALMAS_CHIP_ID 0xC035
#define PALMAS_CHIP_CHARGER_ID 0xC036
+#define TPS65917_RESERVED -1
+
#define is_palmas(a) (((a) == PALMAS_CHIP_OLD_ID) || \
((a) == PALMAS_CHIP_ID))
#define is_palmas_charger(a) ((a) == PALMAS_CHIP_CHARGER_ID)
@@ -184,6 +186,27 @@ enum palmas_regulators {
PALMAS_NUM_REGS,
};
+enum tps65917_regulators {
+ /* SMPS regulators */
+ TPS65917_REG_SMPS1,
+ TPS65917_REG_SMPS2,
+ TPS65917_REG_SMPS3,
+ TPS65917_REG_SMPS4,
+ TPS65917_REG_SMPS5,
+ /* LDO regulators */
+ TPS65917_REG_LDO1,
+ TPS65917_REG_LDO2,
+ TPS65917_REG_LDO3,
+ TPS65917_REG_LDO4,
+ TPS65917_REG_LDO5,
+ TPS65917_REG_REGEN1,
+ TPS65917_REG_REGEN2,
+ TPS65917_REG_REGEN3,
+
+ /* Total number of regulators */
+ TPS65917_NUM_REGS,
+};
+
/* External controll signal name */
enum {
PALMAS_EXT_CONTROL_ENABLE1 = 0x1,
@@ -228,6 +251,24 @@ enum palmas_external_requestor_id {
PALMAS_EXTERNAL_REQSTR_ID_MAX,
};
+enum tps65917_external_requestor_id {
+ TPS65917_EXTERNAL_REQSTR_ID_REGEN1,
+ TPS65917_EXTERNAL_REQSTR_ID_REGEN2,
+ TPS65917_EXTERNAL_REQSTR_ID_REGEN3,
+ TPS65917_EXTERNAL_REQSTR_ID_SMPS1,
+ TPS65917_EXTERNAL_REQSTR_ID_SMPS2,
+ TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
+ TPS65917_EXTERNAL_REQSTR_ID_SMPS4,
+ TPS65917_EXTERNAL_REQSTR_ID_SMPS5,
+ TPS65917_EXTERNAL_REQSTR_ID_LDO1,
+ TPS65917_EXTERNAL_REQSTR_ID_LDO2,
+ TPS65917_EXTERNAL_REQSTR_ID_LDO3,
+ TPS65917_EXTERNAL_REQSTR_ID_LDO4,
+ TPS65917_EXTERNAL_REQSTR_ID_LDO5,
+ /* Last entry */
+ TPS65917_EXTERNAL_REQSTR_ID_MAX,
+};
+
struct palmas_pmic_platform_data {
/* An array of pointers to regulator init data indexed by regulator
* ID
@@ -349,6 +390,48 @@ struct palmas_gpadc_result {
#define PALMAS_MAX_CHANNELS 16
+/* Define the tps65917 IRQ numbers */
+enum tps65917_irqs {
+ /* INT1 registers */
+ TPS65917_RESERVED1,
+ TPS65917_PWRON_IRQ,
+ TPS65917_LONG_PRESS_KEY_IRQ,
+ TPS65917_RESERVED2,
+ TPS65917_PWRDOWN_IRQ,
+ TPS65917_HOTDIE_IRQ,
+ TPS65917_VSYS_MON_IRQ,
+ TPS65917_RESERVED3,
+ /* INT2 registers */
+ TPS65917_RESERVED4,
+ TPS65917_OTP_ERROR_IRQ,
+ TPS65917_WDT_IRQ,
+ TPS65917_RESERVED5,
+ TPS65917_RESET_IN_IRQ,
+ TPS65917_FSD_IRQ,
+ TPS65917_SHORT_IRQ,
+ TPS65917_RESERVED6,
+ /* INT3 registers */
+ TPS65917_GPADC_AUTO_0_IRQ,
+ TPS65917_GPADC_AUTO_1_IRQ,
+ TPS65917_GPADC_EOC_SW_IRQ,
+ TPS65917_RESREVED6,
+ TPS65917_RESERVED7,
+ TPS65917_RESERVED8,
+ TPS65917_RESERVED9,
+ TPS65917_VBUS_IRQ,
+ /* INT4 registers */
+ TPS65917_GPIO_0_IRQ,
+ TPS65917_GPIO_1_IRQ,
+ TPS65917_GPIO_2_IRQ,
+ TPS65917_GPIO_3_IRQ,
+ TPS65917_GPIO_4_IRQ,
+ TPS65917_GPIO_5_IRQ,
+ TPS65917_GPIO_6_IRQ,
+ TPS65917_RESERVED10,
+ /* Total Number IRQs */
+ TPS65917_NUM_IRQ,
+};
+
/* Define the palmas IRQ numbers */
enum palmas_irqs {
/* INT1 registers */
@@ -400,6 +483,7 @@ struct palmas_pmic {
int smps123;
int smps457;
+ int smps12;
int range[PALMAS_REG_SMPS10_OUT1];
unsigned int ramp_delay[PALMAS_REG_SMPS10_OUT1];
@@ -2871,6 +2955,715 @@ enum usb_irq_events {
#define PALMAS_GPADC_TRIM150x0E
#define PALMAS_GPADC_TRIM160x0F
+/* TPS65917 Interrupt registers */
+
+/* Registers for function INTERRUPT */
+#define TPS65917_INT1_STATUS 0x00
+#define TPS65917_INT1_MASK 0x01
+#define TPS65917_INT1_LINE_STATE 0x02
+#define TPS65917_INT2_STATUS 0x05
+#define TPS65917_INT2_MASK 0x06
+#define TPS65917_INT2_LINE_STATE 0x07
+#define TPS65917_INT3_STATUS 0x0A
+#define TPS65917_INT3_MASK 0x0B
+#define TPS65917_INT3_LINE_STATE 0x0C
+#define TPS65917_INT4_STATUS 0x0F
+#define TPS65917_INT4_MASK 0x10
+#define TPS65917_INT4_LINE_STATE 0x11
+#define TPS65917_INT4_EDGE_DETECT1
[PATCH v2 4/9] mfd: palmas: Add tps65917 support
Add tps65917 PMIC support. tps65917 is a subset of palmas PMIC.
Some of the register definitions and the interrupt mappings
are different.
Acked-by: Lee Jones
Signed-off-by: Keerthy
---
Changes in v2:
* Removed redundant features variable.
drivers/mfd/palmas.c | 179 --
1 file changed, 172 insertions(+), 7 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index d280d78..6e17861 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -92,6 +92,133 @@ static const struct regmap_config
palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
},
};
+static const struct regmap_irq tps65917_irqs[] = {
+ /* INT1 IRQs */
+ [TPS65917_RESERVED1] = {
+ .mask = TPS65917_RESERVED,
+ },
+ [TPS65917_PWRON_IRQ] = {
+ .mask = TPS65917_INT1_STATUS_PWRON,
+ },
+ [TPS65917_LONG_PRESS_KEY_IRQ] = {
+ .mask = TPS65917_INT1_STATUS_LONG_PRESS_KEY,
+ },
+ [TPS65917_RESERVED2] = {
+ .mask = TPS65917_RESERVED,
+ },
+ [TPS65917_PWRDOWN_IRQ] = {
+ .mask = TPS65917_INT1_STATUS_PWRDOWN,
+ },
+ [TPS65917_HOTDIE_IRQ] = {
+ .mask = TPS65917_INT1_STATUS_HOTDIE,
+ },
+ [TPS65917_VSYS_MON_IRQ] = {
+ .mask = TPS65917_INT1_STATUS_VSYS_MON,
+ },
+ [TPS65917_RESERVED3] = {
+ .mask = TPS65917_RESERVED,
+ },
+ /* INT2 IRQs*/
+ [TPS65917_RESERVED4] = {
+ .mask = TPS65917_RESERVED,
+ .reg_offset = 1,
+ },
+ [TPS65917_OTP_ERROR_IRQ] = {
+ .mask = TPS65917_INT2_STATUS_OTP_ERROR,
+ .reg_offset = 1,
+ },
+ [TPS65917_WDT_IRQ] = {
+ .mask = TPS65917_INT2_STATUS_WDT,
+ .reg_offset = 1,
+ },
+ [TPS65917_RESERVED5] = {
+ .mask = TPS65917_RESERVED,
+ .reg_offset = 1,
+ },
+ [TPS65917_RESET_IN_IRQ] = {
+ .mask = TPS65917_INT2_STATUS_RESET_IN,
+ .reg_offset = 1,
+ },
+ [TPS65917_FSD_IRQ] = {
+ .mask = TPS65917_INT2_STATUS_FSD,
+ .reg_offset = 1,
+ },
+ [TPS65917_SHORT_IRQ] = {
+ .mask = TPS65917_INT2_STATUS_SHORT,
+ .reg_offset = 1,
+ },
+ [TPS65917_RESERVED6] = {
+ .mask = TPS65917_RESERVED,
+ .reg_offset = 1,
+ },
+ /* INT3 IRQs */
+ [TPS65917_GPADC_AUTO_0_IRQ] = {
+ .mask = TPS65917_INT3_STATUS_GPADC_AUTO_0,
+ .reg_offset = 2,
+ },
+ [TPS65917_GPADC_AUTO_1_IRQ] = {
+ .mask = TPS65917_INT3_STATUS_GPADC_AUTO_1,
+ .reg_offset = 2,
+ },
+ [TPS65917_GPADC_EOC_SW_IRQ] = {
+ .mask = TPS65917_INT3_STATUS_GPADC_EOC_SW,
+ .reg_offset = 2,
+ },
+ [TPS65917_RESREVED6] = {
+ .mask = TPS65917_RESERVED6,
+ .reg_offset = 2,
+ },
+ [TPS65917_RESERVED7] = {
+ .mask = TPS65917_RESERVED,
+ .reg_offset = 2,
+ },
+ [TPS65917_RESERVED8] = {
+ .mask = TPS65917_RESERVED,
+ .reg_offset = 2,
+ },
+ [TPS65917_RESERVED9] = {
+ .mask = TPS65917_RESERVED,
+ .reg_offset = 2,
+ },
+ [TPS65917_VBUS_IRQ] = {
+ .mask = TPS65917_INT3_STATUS_VBUS,
+ .reg_offset = 2,
+ },
+ /* INT4 IRQs */
+ [TPS65917_GPIO_0_IRQ] = {
+ .mask = TPS65917_INT4_STATUS_GPIO_0,
+ .reg_offset = 3,
+ },
+ [TPS65917_GPIO_1_IRQ] = {
+ .mask = TPS65917_INT4_STATUS_GPIO_1,
+ .reg_offset = 3,
+ },
+ [TPS65917_GPIO_2_IRQ] = {
+ .mask = TPS65917_INT4_STATUS_GPIO_2,
+ .reg_offset = 3,
+ },
+ [TPS65917_GPIO_3_IRQ] = {
+ .mask = TPS65917_INT4_STATUS_GPIO_3,
+ .reg_offset = 3,
+ },
+ [TPS65917_GPIO_4_IRQ] = {
+ .mask = TPS65917_INT4_STATUS_GPIO_4,
+ .reg_offset = 3,
+ },
+ [TPS65917_GPIO_5_IRQ] = {
+ .mask = TPS65917_INT4_STATUS_GPIO_5,
+ .reg_offset = 3,
+ },
+ [TPS65917_GPIO_6_IRQ] = {
+ .mask = TPS65917_INT4_STATUS_GPIO_6,
+ .reg_offset = 3,
+ },
+ [TPS65917_RESERVED10] = {
+ .mask = TPS65917_RESERVED10,
+ .reg_offset = 3,
+ },
+};
+
static const struct regmap_irq palmas_irqs[] = {
/* INT1 IRQs */
[PALMAS_CHARG_DET_N_VBUS_OVV_IRQ] = {
@@ -232,6 +359,19 @@ static struct regmap_irq_chip palmas_irq_chip = {
PALMAS_INT1_MASK),
};
+static struct regmap_irq_chip tps65917_irq_chip = {
+ .name = "tps65917",
+ .irqs = tps65917_irq
[PATCH v2 5/9] regulator: palmas: Shift the reg_info structure definition to the header file
Shift the reg_info structure definition to the header file.
Acked-by: Lee Jones
Signed-off-by: Keerthy
---
drivers/regulator/palmas-regulator.c |9 -
include/linux/mfd/palmas.h |9 +
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index b982f0f..1cf462f 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -27,15 +27,6 @@
#include
#include
-struct regs_info {
- char*name;
- char*sname;
- u8 vsel_addr;
- u8 ctrl_addr;
- u8 tstep_addr;
- int sleep_id;
-};
-
static const struct regulator_linear_range smps_low_ranges[] = {
REGULATOR_LINEAR_RANGE(0, 0x0, 0x0, 0),
REGULATOR_LINEAR_RANGE(50, 0x1, 0x6, 0),
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index f760a07..c123666 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -88,6 +88,15 @@ struct palmas {
u8 pwm_muxed;
};
+struct regs_info {
+ char*name;
+ char*sname;
+ u8 vsel_addr;
+ u8 ctrl_addr;
+ u8 tstep_addr;
+ int sleep_id;
+};
+
struct palmas_gpadc_platform_data {
/* Channel 3 current source is only enabled during conversion */
int ch3_current;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 7/9] regulator: palmas: Add palmas_pmic_driver_data structure
Add palmas_pmic_driver_data structure.
Signed-off-by: Keerthy
---
include/linux/mfd/palmas.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index 0136e58..1a045ba 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -53,6 +53,8 @@ struct palmas_pmic;
struct palmas_gpadc;
struct palmas_resource;
struct palmas_usb;
+struct palmas_pmic_driver_data;
+struct palmas_pmic_platform_data;
enum palmas_usb_state {
PALMAS_USB_STATE_DISCONNECT,
@@ -76,6 +78,8 @@ struct palmas {
struct mutex irq_lock;
struct regmap_irq_chip_data *irq_data;
+ struct palmas_pmic_driver_data *pmic_ddata;
+
/* Child Devices */
struct palmas_pmic *pmic;
struct palmas_gpadc *gpadc;
@@ -107,6 +111,27 @@ struct regs_info {
int sleep_id;
};
+struct palmas_pmic_driver_data {
+ int smps_start;
+ int smps_end;
+ int ldo_begin;
+ int ldo_end;
+ int max_reg;
+ struct regs_info *palmas_regs_info;
+ struct of_regulator_match *palmas_matches;
+ struct palmas_sleep_requestor_info *sleep_req_info;
+ int (*smps_register)(struct palmas_pmic *pmic,
+struct palmas_pmic_driver_data *ddata,
+struct palmas_pmic_platform_data *pdata,
+const char *pdev_name,
+struct regulator_config config);
+ int (*ldo_register)(struct palmas_pmic *pmic,
+ struct palmas_pmic_driver_data *ddata,
+ struct palmas_pmic_platform_data *pdata,
+ const char *pdev_name,
+ struct regulator_config config);
+};
+
struct palmas_gpadc_platform_data {
/* Channel 3 current source is only enabled during conversion */
int ch3_current;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 9/9] regulator: palmas: Add tps65917 PMIC support
Add tps65917 PMIC support.
Signed-off-by: Keerthy
---
drivers/regulator/palmas-regulator.c | 387 ++
1 file changed, 387 insertions(+)
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index aa8e551..8fa651e 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -227,6 +227,94 @@ static struct regs_info palmas_regs_info[] = {
},
};
+static struct regs_info tps65917_regs_info[] = {
+ {
+ .name = "SMPS1",
+ .sname = "smps1-in",
+ .vsel_addr = TPS65917_SMPS1_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS1_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS1,
+ },
+ {
+ .name = "SMPS2",
+ .sname = "smps2-in",
+ .vsel_addr = TPS65917_SMPS2_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS2_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS2,
+ },
+ {
+ .name = "SMPS3",
+ .sname = "smps3-in",
+ .vsel_addr = TPS65917_SMPS3_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS3_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS3,
+ },
+ {
+ .name = "SMPS4",
+ .sname = "smps4-in",
+ .vsel_addr = TPS65917_SMPS4_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS4_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS4,
+ },
+ {
+ .name = "SMPS5",
+ .sname = "smps5-in",
+ .vsel_addr = TPS65917_SMPS5_VOLTAGE,
+ .ctrl_addr = TPS65917_SMPS5_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_SMPS5,
+ },
+ {
+ .name = "LDO1",
+ .sname = "ldo1-in",
+ .vsel_addr = TPS65917_LDO1_VOLTAGE,
+ .ctrl_addr = TPS65917_LDO1_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_LDO1,
+ },
+ {
+ .name = "LDO2",
+ .sname = "ldo2-in",
+ .vsel_addr = TPS65917_LDO2_VOLTAGE,
+ .ctrl_addr = TPS65917_LDO2_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_LDO2,
+ },
+ {
+ .name = "LDO3",
+ .sname = "ldo3-in",
+ .vsel_addr = TPS65917_LDO3_VOLTAGE,
+ .ctrl_addr = TPS65917_LDO3_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_LDO3,
+ },
+ {
+ .name = "LDO4",
+ .sname = "ldo4-in",
+ .vsel_addr = TPS65917_LDO4_VOLTAGE,
+ .ctrl_addr = TPS65917_LDO4_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_LDO4,
+ },
+ {
+ .name = "LDO5",
+ .sname = "ldo5-in",
+ .vsel_addr = TPS65917_LDO5_VOLTAGE,
+ .ctrl_addr = TPS65917_LDO5_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_LDO5,
+ },
+ {
+ .name = "REGEN1",
+ .ctrl_addr = TPS65917_REGEN1_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_REGEN1,
+ },
+ {
+ .name = "REGEN2",
+ .ctrl_addr = TPS65917_REGEN2_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_REGEN2,
+ },
+ {
+ .name = "REGEN3",
+ .ctrl_addr = TPS65917_REGEN3_CTRL,
+ .sleep_id = TPS65917_EXTERNAL_REQSTR_ID_REGEN3,
+ },
+};
+
#define EXTERNAL_REQUESTOR(_id, _offset, _pos) \
[PALMAS_EXTERNAL_REQSTR_ID_##_id] = { \
.id = PALMAS_EXTERNAL_REQSTR_ID_##_id, \
@@ -263,6 +351,29 @@ struct palmas_sleep_requestor_info palma_sleep_req_info[]
= {
EXTERNAL_REQUESTOR(LDOUSB, 3, 2),
};
+#define EXTERNAL_REQUESTOR_TPS65917(_id, _offset, _pos)\
+ [TPS65917_EXTERNAL_REQSTR_ID_##_id] = { \
+ .id = TPS65917_EXTERNAL_REQSTR_ID_##_id,\
+ .reg_offset = _offset, \
+ .bit_pos = _pos,\
+ }
+
+static struct palmas_sleep_requestor_info tps65917_sleep_req_info[] = {
+ EXTERNAL_REQUESTOR_TPS65917(REGEN1, 0, 0),
+ EXTERNAL_REQUESTOR_TPS65917(REGEN2, 0, 1),
+ EXTERNAL_REQUESTOR_TPS65917(REGEN3, 0, 6),
+ EXTERNAL_REQUESTOR_TPS65917(SMPS1, 1, 0),
+ EXTERNAL_REQUESTOR_TPS65917(SMPS2, 1, 1),
+ EXTERNAL_REQUESTOR_TPS65917(SMPS3, 1, 2),
+
[PATCH v2 6/9] mfd: palmas: shift the palmas_sleep_requestor_info structure definition to the header file
shift the palmas_sleep_requestor_info structure definition to the header file.
Acked-by: Lee Jones
Signed-off-by: Keerthy
---
drivers/mfd/palmas.c | 10 --
include/linux/mfd/palmas.h | 10 ++
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index 6e17861..c12759d 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -25,16 +25,6 @@
#include
#include
-#define PALMAS_EXT_REQ (PALMAS_EXT_CONTROL_ENABLE1 | \
- PALMAS_EXT_CONTROL_ENABLE2 |\
- PALMAS_EXT_CONTROL_NSLEEP)
-
-struct palmas_sleep_requestor_info {
- int id;
- int reg_offset;
- int bit_pos;
-};
-
#define EXTERNAL_REQUESTOR(_id, _offset, _pos) \
[PALMAS_EXTERNAL_REQSTR_ID_##_id] = { \
.id = PALMAS_EXTERNAL_REQSTR_ID_##_id, \
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index c123666..0136e58 100644
--- a/include/linux/mfd/palmas.h
+++ b/include/linux/mfd/palmas.h
@@ -88,6 +88,16 @@ struct palmas {
u8 pwm_muxed;
};
+#define PALMAS_EXT_REQ (PALMAS_EXT_CONTROL_ENABLE1 | \
+ PALMAS_EXT_CONTROL_ENABLE2 |\
+ PALMAS_EXT_CONTROL_NSLEEP)
+
+struct palmas_sleep_requestor_info {
+ int id;
+ int reg_offset;
+ int bit_pos;
+};
+
struct regs_info {
char*name;
char*sname;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 8/9] regulator: palmas: add driver data and modularize the probe
add driver data and modularize the probe.
Signed-off-by: Keerthy
---
Changes in V2:
* Fixed the order of variable declarations.
drivers/mfd/palmas.c | 44 +--
drivers/regulator/palmas-regulator.c | 658 --
2 files changed, 396 insertions(+), 306 deletions(-)
diff --git a/drivers/mfd/palmas.c b/drivers/mfd/palmas.c
index c12759d..28cb048 100644
--- a/drivers/mfd/palmas.c
+++ b/drivers/mfd/palmas.c
@@ -25,42 +25,6 @@
#include
#include
-#define EXTERNAL_REQUESTOR(_id, _offset, _pos) \
- [PALMAS_EXTERNAL_REQSTR_ID_##_id] = { \
- .id = PALMAS_EXTERNAL_REQSTR_ID_##_id, \
- .reg_offset = _offset, \
- .bit_pos = _pos,\
- }
-
-static struct palmas_sleep_requestor_info sleep_req_info[] = {
- EXTERNAL_REQUESTOR(REGEN1, 0, 0),
- EXTERNAL_REQUESTOR(REGEN2, 0, 1),
- EXTERNAL_REQUESTOR(SYSEN1, 0, 2),
- EXTERNAL_REQUESTOR(SYSEN2, 0, 3),
- EXTERNAL_REQUESTOR(CLK32KG, 0, 4),
- EXTERNAL_REQUESTOR(CLK32KGAUDIO, 0, 5),
- EXTERNAL_REQUESTOR(REGEN3, 0, 6),
- EXTERNAL_REQUESTOR(SMPS12, 1, 0),
- EXTERNAL_REQUESTOR(SMPS3, 1, 1),
- EXTERNAL_REQUESTOR(SMPS45, 1, 2),
- EXTERNAL_REQUESTOR(SMPS6, 1, 3),
- EXTERNAL_REQUESTOR(SMPS7, 1, 4),
- EXTERNAL_REQUESTOR(SMPS8, 1, 5),
- EXTERNAL_REQUESTOR(SMPS9, 1, 6),
- EXTERNAL_REQUESTOR(SMPS10, 1, 7),
- EXTERNAL_REQUESTOR(LDO1, 2, 0),
- EXTERNAL_REQUESTOR(LDO2, 2, 1),
- EXTERNAL_REQUESTOR(LDO3, 2, 2),
- EXTERNAL_REQUESTOR(LDO4, 2, 3),
- EXTERNAL_REQUESTOR(LDO5, 2, 4),
- EXTERNAL_REQUESTOR(LDO6, 2, 5),
- EXTERNAL_REQUESTOR(LDO7, 2, 6),
- EXTERNAL_REQUESTOR(LDO8, 2, 7),
- EXTERNAL_REQUESTOR(LDO9, 3, 0),
- EXTERNAL_REQUESTOR(LDOLN, 3, 1),
- EXTERNAL_REQUESTOR(LDOUSB, 3, 2),
-};
-
static const struct regmap_config palmas_regmap_config[PALMAS_NUM_CLIENTS] = {
{
.reg_bits = 8,
@@ -365,10 +329,10 @@ static struct regmap_irq_chip tps65917_irq_chip = {
int palmas_ext_control_req_config(struct palmas *palmas,
enum palmas_external_requestor_id id, int ext_ctrl, bool enable)
{
+ struct palmas_pmic_driver_data *pmic_ddata = palmas->pmic_ddata;
int preq_mask_bit = 0;
int reg_add = 0;
- int bit_pos;
- int ret;
+ int bit_pos, ret;
if (!(ext_ctrl & PALMAS_EXT_REQ))
return 0;
@@ -387,8 +351,8 @@ int palmas_ext_control_req_config(struct palmas *palmas,
preq_mask_bit = 2;
}
- bit_pos = sleep_req_info[id].bit_pos;
- reg_add += sleep_req_info[id].reg_offset;
+ bit_pos = pmic_ddata->sleep_req_info[id].bit_pos;
+ reg_add += pmic_ddata->sleep_req_info[id].reg_offset;
if (enable)
ret = palmas_update_bits(palmas, PALMAS_RESOURCE_BASE,
reg_add, BIT(bit_pos), BIT(bit_pos));
diff --git a/drivers/regulator/palmas-regulator.c
b/drivers/regulator/palmas-regulator.c
index 1cf462f..aa8e551 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -41,7 +41,7 @@ static const struct regulator_linear_range smps_high_ranges[]
= {
REGULATOR_LINEAR_RANGE(330, 0x7A, 0x7f, 0),
};
-static const struct regs_info palmas_regs_info[] = {
+static struct regs_info palmas_regs_info[] = {
{
.name = "SMPS12",
.sname = "smps1-in",
@@ -227,6 +227,42 @@ static const struct regs_info palmas_regs_info[] = {
},
};
+#define EXTERNAL_REQUESTOR(_id, _offset, _pos) \
+ [PALMAS_EXTERNAL_REQSTR_ID_##_id] = { \
+ .id = PALMAS_EXTERNAL_REQSTR_ID_##_id, \
+ .reg_offset = _offset, \
+ .bit_pos = _pos,\
+ }
+
+struct palmas_sleep_requestor_info palma_sleep_req_info[] = {
+ EXTERNAL_REQUESTOR(REGEN1, 0, 0),
+ EXTERNAL_REQUESTOR(REGEN2, 0, 1),
+ EXTERNAL_REQUESTOR(SYSEN1, 0, 2),
+ EXTERNAL_REQUESTOR(SYSEN2, 0, 3),
+ EXTERNAL_REQUESTOR(CLK32KG, 0, 4),
+ EXTERNAL_REQUESTOR(CLK32KGAUDIO, 0, 5),
+ EXTERNAL_REQUESTOR(REGEN3, 0, 6),
+ EXTERNAL_REQUESTOR(SMPS12, 1, 0),
+ EXTERNAL_REQUESTOR(SMPS3, 1, 1),
+ EXTERNAL_REQUESTOR(SMPS45, 1, 2),
+ EXTERNAL_REQUESTOR(SMPS6, 1, 3),
+ EXTERNAL_REQUESTOR(SMPS7, 1, 4),
+ EXTERNAL_REQUESTOR(SMPS8, 1, 5),
+ EXTERNAL_REQUESTOR(SMPS9, 1, 6),
+ EXTERNAL_REQUESTOR(SMPS10, 1, 7),
+ EXTERNAL_REQUESTOR(LDO1, 2, 0),
+ EXTERNAL_REQUESTOR(LDO2, 2, 1),
+ EXTERNAL_REQUESTOR(LDO3, 2, 2),
+ EXTERNAL_REQUESTOR(LDO4, 2, 3),
+ EXTERNAL_REQUESTOR(LDO5, 2, 4),
+ EXTERNAL_REQUESTOR(LDO6, 2, 5),
+ EXTERNAL_REQUESTOR(LDO7, 2, 6),
+ EXTERNAL_REQUESTOR(LDO8,
[PATCH v2 1/9] mfd: Add DT bindings for tps65917 PMIC
Add DT bindings for tps65917 PMIC. Signed-off-by: Keerthy --- Documentation/devicetree/bindings/mfd/palmas.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt index e5f0f83..eda8989 100644 --- a/Documentation/devicetree/bindings/mfd/palmas.txt +++ b/Documentation/devicetree/bindings/mfd/palmas.txt @@ -6,6 +6,7 @@ twl6037 (palmas) tps65913 (palmas) tps65914 (palmas) tps659038 +tps65917 Required properties: - compatible : Should be from the list @@ -16,6 +17,7 @@ Required properties: ti,tps65914 ti,tps80036 ti,tps659038 + ti,tps65917 and also the generic series names ti,palmas - interrupt-controller : palmas has its own internal IRQs -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/18] PCI: designware: Configuration space should be specified in 'reg'
On Wednesday, June 18, 2014 6:15 PM, Kishon Vijay Abraham I wrote:
> On Friday 30 May 2014 07:45 PM, Karicheri, Muralidharan wrote:
> >> On 5/29/2014 2:38 AM, ABRAHAM, KISHON VIJAY wrote:
> >>> The configuration address space has so far been specified in *ranges*,
> >>> however it should be specified in *reg* making it a platform MEM resource.
> >>> Hence used 'platform_get_resource_*' API to get configuration address
> >>> space in the designware driver.
> >>>
> >>> Cc: Jason Gunthorpe
> >>> Cc: Bjorn Helgaas
> >>> Cc: Mohit Kumar
> >>> Cc: Jingoo Han
> >>> Cc: Marek Vasut
> >>> Cc: Arnd Bergmann
> >>> Signed-off-by: Kishon Vijay Abraham I
> >>> ---
> >>> .../devicetree/bindings/pci/designware-pcie.txt|1 +
> >>> drivers/pci/host/pcie-designware.c | 17
> >>> +++--
> >>> 2 files changed, 16 insertions(+), 2 deletions(-)
[...]
> >>> + cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
> >>> + if (cfg_res) {
> >>> + pp->config.cfg0_size = resource_size(cfg_res)/2;
> >>> + pp->config.cfg1_size = resource_size(cfg_res)/2;
> >>> + pp->cfg0_base = cfg_res->start;
> >>> + pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
> >>> + } else {
> >>> + dev_err(pp->dev, "missing *config* reg space\n");
> >> This should return error -EINVAL.
>
> Just read the other thread and Grant Likely suggested the host controller
> driver should be backward compatible [1]. So we can't return -EINVAL here.
> So I'd assume this patch is fine as is? Arnd? Jingoo?
Yes, you're right. The driver should keep backward compatibility for
legacy DT binding. However, after enough time goes by, these legacy
DT handling can be removed.
Best regards,
Jingoo Han
>
> [1] -> https://lkml.org/lkml/2014/6/3/124
>
> Thanks
> Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 03/18] PCI: designware: Configuration space should be specified in 'reg'
Hi,
On Friday 30 May 2014 07:45 PM, Karicheri, Muralidharan wrote:
>> -Original Message-
>> From: Murali Karicheri [mailto:m-kariche...@ti.com]
>> Sent: Thursday, May 29, 2014 12:32 PM
>> To: ABRAHAM, KISHON VIJAY
>> Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-
>> ker...@lists.infradead.org; linux-omap@vger.kernel.org;
>> linux-...@vger.kernel.org; linux-
>> ker...@vger.kernel.org; a...@arndb.de; t...@atomide.com; jg1@samsung.com;
>> Jason Gunthorpe; Bjorn Helgaas; Mohit Kumar; Marek Vasut
>> Subject: Re: [PATCH v2 03/18] PCI: designware: Configuration space should be
>> specified
>> in 'reg'
>>
>> On 5/29/2014 2:38 AM, ABRAHAM, KISHON VIJAY wrote:
>>> The configuration address space has so far been specified in *ranges*,
>>> however it should be specified in *reg* making it a platform MEM resource.
>>> Hence used 'platform_get_resource_*' API to get configuration address
>>> space in the designware driver.
>>>
>>> Cc: Jason Gunthorpe
>>> Cc: Bjorn Helgaas
>>> Cc: Mohit Kumar
>>> Cc: Jingoo Han
>>> Cc: Marek Vasut
>>> Cc: Arnd Bergmann
>>> Signed-off-by: Kishon Vijay Abraham I
>>> ---
>>> .../devicetree/bindings/pci/designware-pcie.txt|1 +
>>> drivers/pci/host/pcie-designware.c | 17
>>> +++--
>>> 2 files changed, 16 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>>> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>>> index d6fae13..8314360 100644
>>> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
>>> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
>>> @@ -6,6 +6,7 @@ Required properties:
>>> as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
>>> - reg: base addresses and lengths of the pcie controller,
>>> the phy controller, additional register for the phy controller.
>>> + The configuration address space should also be specified here.
>> Kishon,
>>
>> I am working on the Keystone PCI driver for which v1 is already posted.
>> Want to clarify
>> following.
>> 1. Original text for reg states "base addresses and lengths of the pcie
>> controller,
>> the phy controller, additional register for the phy controller"
>> and you added
>> "The configuration address space should also be specified here"
>>
>>and the code below added resource name "config"
>>
>> Does PCI designware follow some convention? Does it mean after applying this
>> patch
>> config name is mandatory or optional? Below code you are not returning
>> error. Can you or
>> author of PCI designware clarify what is expected to be present as mandatory
>> and what is
>> optional.
>>
>> Does config refers to RC's config space or EP's config space or both?
>> The code below divide
>> the size by 2. So it appears to be RC's + EP's config space. Please clarify.
>>
>>> - interrupts: interrupt values for level interrupt,
>>> pulse interrupt, special interrupt.
>>> - clocks: from common clock binding: handle to pci clock.
>>> diff --git a/drivers/pci/host/pcie-designware.c
>>> b/drivers/pci/host/pcie-designware.c
>>> index c4e3732..603b386 100644
>>> --- a/drivers/pci/host/pcie-designware.c
>>> +++ b/drivers/pci/host/pcie-designware.c
>>> @@ -20,6 +20,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>>
>>> #include "pcie-designware.h"
>>> @@ -392,11 +393,23 @@ static const struct irq_domain_ops msi_domain_ops = {
>>> int __init dw_pcie_host_init(struct pcie_port *pp)
>>> {
>>> struct device_node *np = pp->dev->of_node;
>>> + struct platform_device *pdev = to_platform_device(pp->dev);
>>> struct of_pci_range range;
>>> struct of_pci_range_parser parser;
>>> + struct resource *cfg_res;
>>> u32 val;
>>> int i;
>>>
>>> + cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
>>> + if (cfg_res) {
>>> + pp->config.cfg0_size = resource_size(cfg_res)/2;
>>> + pp->config.cfg1_size = resource_size(cfg_res)/2;
>>> + pp->cfg0_base = cfg_res->start;
>>> + pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
>>> + } else {
>>> + dev_err(pp->dev, "missing *config* reg space\n");
>> This should return error -EINVAL.
Just read the other thread and Grant Likely suggested the host controller
driver should be backward compatible [1]. So we can't return -EINVAL here.
So I'd assume this patch is fine as is? Arnd? Jingoo?
[1] -> https://lkml.org/lkml/2014/6/3/124
Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 04/18] PCI: designware: use untranslated address while programming ATU
Hi Arnd,
On Thursday 29 May 2014 12:08 PM, Kishon Vijay Abraham I wrote:
> In DRA7, the cpu sees 32bit address, but the pcie controller can see only
> 28bit
> address. So whenever the cpu issues a read/write request, the 4 most
> significant bits are used by L3 to determine the target controller.
> For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller
> but
> the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming
> the outbound translation window the *base* should be programmed as 0x000_.
> Whenever we try to write to say 0x2000_, it will be translated to whatever
> we have programmed in the translation window with base as 0x000_.
>
> This is needed when the dt node is modelled something like below
> axi {
> compatible = "simple-bus";
> #size-cells = <1>;
> #address-cells = <1>;
> ranges = <0x00x2000 0x1000 // 28-bit bus
> 0x5100 0x5100 0x3000>;
> pcie@5100 {
> reg = <0x1000 0x2000>, <0x51002000 0x14c>, <0x5100 0x2000>;
> reg-names = "config", "ti_conf", "rc_dbics";
> #address-cells = <3>;
> #size-cells = <2>;
> ranges = <0x8100 0 0 0x03000 0 0x0001
> 0x8200 0 0x20013000 0x13000 0 0xffed000>;
> };
> };
>
> Here the CPU address for configuration space is 0x20013000 and the controller
> address for configuration space is 0x13000. The controller address should be
> used while programming the ATU (in order for translation to happen properly in
> DRA7xx).
I've fixed this up with what you suggested in the v1 of the series. Do you
think this is fine?
Thanks
Kishon
>
> Cc: Jason Gunthorpe
> Cc: Bjorn Helgaas
> Cc: Mohit Kumar
> Cc: Jingoo Han
> Cc: Marek Vasut
> Cc: Arnd Bergmann
> Signed-off-by: Kishon Vijay Abraham I
> ---
> drivers/pci/host/pcie-designware.c | 49
>
> drivers/pci/host/pcie-designware.h |4 +++
> 2 files changed, 42 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/pci/host/pcie-designware.c
> b/drivers/pci/host/pcie-designware.c
> index 603b386..9dfd2d4 100644
> --- a/drivers/pci/host/pcie-designware.c
> +++ b/drivers/pci/host/pcie-designware.c
> @@ -397,8 +397,15 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> struct of_pci_range range;
> struct of_pci_range_parser parser;
> struct resource *cfg_res;
> - u32 val;
> - int i;
> + u32 val, na, ns;
> + const __be32 *addrp;
> + int i, index;
> +
> + /* Find the address cell size and the number of cells in order to get
> + * the untranslated address.
> + */
> + of_property_read_u32(np, "#address-cells", &na);
> + ns = of_n_size_cells(np);
>
> cfg_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "config");
> if (cfg_res) {
> @@ -406,6 +413,12 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> pp->config.cfg1_size = resource_size(cfg_res)/2;
> pp->cfg0_base = cfg_res->start;
> pp->cfg1_base = cfg_res->start + pp->config.cfg0_size;
> +
> + /* Find the untranslated configuration space address */
> + index = of_property_match_string(np, "reg-names", "config");
> + addrp = of_get_address(np, index, false, false);
> + pp->cfg0_mod_addr = of_read_number(addrp, ns);
> + pp->cfg1_mod_addr = pp->cfg0_mod_addr + pp->config.cfg0_size;
> } else {
> dev_err(pp->dev, "missing *config* reg space\n");
> }
> @@ -431,12 +444,20 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> pp->config.io_size = resource_size(&pp->io);
> pp->config.io_bus_addr = range.pci_addr;
> pp->io_base = range.cpu_addr;
> +
> + /* Find the untranslated IO space address */
> + pp->io_mod_addr = of_read_number(parser.range -
> + parser.np + na, ns);
> }
> if (restype == IORESOURCE_MEM) {
> of_pci_range_to_resource(&range, np, &pp->mem);
> pp->mem.name = "MEM";
> pp->config.mem_size = resource_size(&pp->mem);
> pp->config.mem_bus_addr = range.pci_addr;
> +
> + /* Find the untranslated MEM space address */
> + pp->mem_mod_addr = of_read_number(parser.range -
> + parser.np + na, ns);
> }
> if (restype == 0) {
> of_pci_range_to_resource(&range, np, &pp->cfg);
> @@ -444,6 +465,12 @@ int __init dw_pcie_host_init(struct pcie_port *pp)
> pp->config.cfg1_size = resource_size(&pp->cfg)/2;
> pp->cfg0_base = pp
RE: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Hi,
>From: Jason Kridner [mailto:jkrid...@gmail.com]
>>On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon wrote:
>>>From: Jason Kridner
[...]
* The devicetree sources, including the primary boot .dts files, will
eventually be removed from the kernel source tree. I'm not too sure if
and when it'll really happen, but starting up a project to maintain
the definitive beagleboard.org board devicetree files outside the
kernel seems to make sense. Given the interdependency of the boot .dtb
and the overlay .dtbo files, combining them into a single repository
where every distribution can pick them up seems like a natural and
obvious choice. There are of course some dependencies on kernel
versions, but I believe most of those have settled out by now and we
should be OK moving forward.
>>
>> +1
>> Yes, moving cape DTS out of kernel tree should help developers.
>> There are quite a few cape patches floating in mail-lists, but as cape
>> DTS is still not accepted in mainline so they get lost and forgotten.
>> So one place for collecting all this is a good idea.
>>
>>
>> However, somehow the universal I/O DTS looked seemed complicated:
>> (1)
>> All capes work standalone, but due to share pin-mux some cape
>> combinations cannot be used simultaneously. But most users of
>> BeagleBone are already well-versed with DT and kernel infrastructure,
>> so they need not be spoon fed to get a out-of-box working solution
>> for each combination. If there is proper documentation is available
>> about compatibility of capes with each other, then users will figure
>> out themselves.
>
>I think you have too much confidence in users. If this doesn't hurt
>power users, then why is it bad have an option to spoon feed? This
>doesn't prevent anyone with knowledge of DT from doing their own
>thing.
>
Fair enough.
But plz give a try to u-boot alternative below. It works at my end.
>>
>> (2)
>> Also, there was a talk of enabling and disabling DT fragments via u-boot.
>> That should also be explored instead of complicating cape DTS.
>
>Link? Relevance?
>
we can modify DT from u-boot itself [1].
Example: "MMC2" pin-mux conflicts with "NAND" and "NOR" capes.
But using following sequence of commands, you can modify DTB via
u-boot and make NAND cape work _without_any_hack_ in patch [2].
/* load DTB */
u-boot> tftp 0x8100 am335x-boneblack.dtb
u-boot> fdt addr 0x8100
/* disable MMC2 node */
u-boot> fdt list /ocp/mmc@481d8000
u-boot> fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
u-boot> fdt list /ocp/mmc@481d8000 status
/* enable GPMC node */
u-boot> fdt list /ocp/gpmc
u-boot> fdt set /ocp/gpmc status \o\k\a\y
u-boot> fdt list /ocp/gpmc status
/* enable ELM node */
u-boot> fdt list /ocp/elm
u-boot> fdt set /ocp/elm status \o\k\a\y
u-boot> fdt list /ocp/elm status
/* boot uImage */
tftp 0x8200 uImage
bootm 0x8200 - 0x8100
Note: "fdt set" command does not accept string literals
as binding values, it internally converts them to string, so
escape sequenced characters were used here..
"okay" == \o\k\a\y
"disabled" == \d\i\s\a\b\l\e\d"
Hope above solves the pre-requisite because of which 'Tony Lindgren
'
was unable to accept cape related DTS into his tree [3]
[1] http://www.denx.de/wiki/view/DULG/UBootCmdFDT
[2] http://www.spinics.net/lists/linux-omap/msg107307.html
[3] http://www.spinics.net/lists/linux-omap/msg107354.html
with regards, pekon
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
On 04/23/2014 08:35 PM, Roger Quadros wrote:
> From: Nikhil Devshatwar
>
> Add hwmods for ocp2scp3 and sata modules.
>
> [Roger Q] Clean up.
>
> CC: Benoit Cousson
> CC: Paul Walmsley
> Signed-off-by: Balaji T K
> Signed-off-by: Nikhil Devshatwar
> Signed-off-by: Roger Quadros
Tested-by: Roger Quadros
against 3.16-rc1, no dependency patches needed.
Nishant/Rajendra,
Could you please review this? We need this for 3.16 SATA support and
Paul won't take this in without your reviewed-by tag. Thanks.
cheers,
-roger
> ---
> arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 31
> ++-
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 810c205..b02a4ab 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1215,6 +1215,30 @@ static struct omap_hwmod dra7xx_ocp2scp1_hwmod = {
> },
> };
>
> +/* ocp2scp3 */
> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod;
> +
> +/* l4_cfg -> ocp2scp3 */
> +static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3 = {
> + .master = &dra7xx_l4_cfg_hwmod,
> + .slave = &dra7xx_ocp2scp3_hwmod,
> + .clk= "l4_root_clk_div",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
> + .name = "ocp2scp3",
> + .class = &dra7xx_ocp2scp_hwmod_class,
> + .clkdm_name = "l3init_clkdm",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs =
> DRA7XX_CM_L3INIT_OCP2SCP3_CLKCTRL_OFFSET,
> + .context_offs =
> DRA7XX_RM_L3INIT_OCP2SCP3_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_HWCTRL,
> + },
> + },
> +};
> +
> /*
> * 'qspi' class
> *
> @@ -1268,9 +1292,6 @@ static struct omap_hwmod_class dra7xx_sata_hwmod_class
> = {
> };
>
> /* sata */
> -static struct omap_hwmod_opt_clk sata_opt_clks[] = {
> - { .role = "ref_clk", .clk = "sata_ref_clk" },
> -};
>
> static struct omap_hwmod dra7xx_sata_hwmod = {
> .name = "sata",
> @@ -1278,6 +1299,7 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
> .clkdm_name = "l3init_clkdm",
> .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> .main_clk = "func_48m_fclk",
> + .mpu_rt_idx = 1,
> .prcm = {
> .omap4 = {
> .clkctrl_offs = DRA7XX_CM_L3INIT_SATA_CLKCTRL_OFFSET,
> @@ -1285,8 +1307,6 @@ static struct omap_hwmod dra7xx_sata_hwmod = {
> .modulemode = MODULEMODE_SWCTRL,
> },
> },
> - .opt_clks = sata_opt_clks,
> - .opt_clks_cnt = ARRAY_SIZE(sata_opt_clks),
> };
>
> /*
> @@ -2682,6 +2702,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
> __initdata = {
> &dra7xx_l4_per1__mmc4,
> &dra7xx_l4_cfg__mpu,
> &dra7xx_l4_cfg__ocp2scp1,
> + &dra7xx_l4_cfg__ocp2scp3,
> &dra7xx_l3_main_1__qspi,
> &dra7xx_l4_cfg__sata,
> &dra7xx_l4_cfg__smartreflex_core,
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] ARM: DRA7: hwmod: Add ocp2scp3 and sata hwmods
+ Rajendra, Nishant and Kevin. as you were mentioned in the discussion. cheers, -roger On 06/15/2014 06:33 AM, Paul Walmsley wrote: > On Fri, 13 Jun 2014, Paul Walmsley wrote: > >> Hi Roger, >> >> On Wed, 23 Apr 2014, Roger Quadros wrote: >> >>> From: Nikhil Devshatwar >>> >>> Add hwmods for ocp2scp3 and sata modules. >>> >>> [Roger Q] Clean up. >> >> Sorry for the delay on this. Have been corresponding with TI to figure >> out what to do about these DRA7xx/AM43xx patches, since I don't have >> boards or public documentation for these devices, so it's impossible for >> me to meaningfully review the patches. Looks like boards and/or public >> docs won't be coming any time soon. >> >> So for my part, here's what I'll need to merge any hwmod patches that >> involve AM437x or DRA7xx: >> >> 1. A Reviewed-by: from one of the following folks (which should come from >> a different person than who is submitting the patches): >> >> Roger Quadros >> Nishanth Menon >> Rajendra Nayak >> Kevin Hilman >> Tony Lindgren >> >> 2. A Tested-by: from one of the following folks (who can be the same as >> the person who is the same as the person who is submitting the patches): >> >> Nishanth Menon >> Rajendra Nayak >> Kevin Hilman >> Tony Lindgren >> >> Once these are in place, I'd be happy to queue it for 3.16. > > I've tried to clarify this a bit. The update is below. > > > - Paul > > > > For boards that I don't have access to, that I don't have > documentation for, such as the AM43xx and DRA7xx), for me to merge or ack > SoC infrastructure or PM-related patches, I want to have: > > 1. a Reviewed-by: from people who: > > a. I think know something about SoC integration or PM in general, and > about OMAP-style integration specifically; and > > b. who have a track record of doing strong and detailed reviews of that > code, or who have contributed significantly to that code in the past. > > My initial list of those reviewers is listed above, and I am happy to > consider extending it or modifying that list. > > > 2. confidence that the patch or series has been tested against a mainline > commit and isn't obviously breaking other things, like PM, and confidence > that it's not adding new runtime warnings. > > I've listed an initial set of people above who I feel have proven track > records in testing who I'm happy to accept Tested-by:s without further > explanation. I'm sure I've missed some folks and if anyone who should be > on that list is offended that I didn't mention them, please accept my > apologies. For other folks, like yourself, who aren't on that list (yet), > please just specifically state: > > a. what mainline commit they've tested the patch against, > > b. what other prerequisite patches were needed for the patch to apply, > > c. and a cut-and-paste of the serial console boot log from the boot > portion of the test. > > in such a way that myself or someone else can easily doublecheck it. > > And frankly, I'll probably be happy to merge it. > > After someone has done these three things a few times, and I gain > confidence that they're doing the right thing, I'm happy to add them to > my list. > > The testing doesn't have to be expressed via a Tested-by: tag in cases > where you're testing as part of a Signed-off-by:. Just be sure to state > those three things above as part of the patch or series message. The boot > log can either be placed on a different page and linked to, or sent in > another public E-mail. > > If you can get two or three people to do the above, that's great - the > more, the better. > > ... > > These two steps do not apply to boards that I have in my testbed or which > I have documentation for (although they would definitely be very welcome > in those cases too). > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: am43x: Fix boot with CONFIG_SOC_AM33XX disabled
On 06/17/2014 05:03 PM, Roger Quadros wrote:
> Define ti_clk_register_dpll_x2() and of_ti_am3_dpll_x2_setup() if
> AM43XX is defined.
>
> Fixes the below boot issue.
>
> [2.157258] gpmc_l3_clk not enabled
> [2.161194] gpmc_l3_clk not enabled
> [2.164896] Division by zero in kernel.
> [2.169055] CPU: 0 PID: 321 Comm: kworker/u2:2 Tainted: GW
> 3.16.0-rc1-8-g4c0e520 #273
> [2.178880] Workqueue: deferwq deferred_probe_work_func
> [2.184459] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [2.192752] [] (show_stack) from []
> (dump_stack+0x80/0x9c)
> [2.200486] [] (dump_stack) from [] (Ldiv0+0x8/0x10)
> [2.207678] [] (Ldiv0) from []
> (gpmc_calc_divider+0x24/0x40)
> [2.215490] [] (gpmc_calc_divider) from []
> (gpmc_cs_set_timings+0x18/0x474)
> [2.224783] [] (gpmc_cs_set_timings) from []
> (gpmc_nand_init+0x74/0x1a8)
> [2.233791] [] (gpmc_nand_init) from []
> (gpmc_probe+0x52c/0x874)
> [2.242089] [] (gpmc_probe) from []
> (platform_drv_probe+0x18/0x48)
> [2.250534] [] (platform_drv_probe) from []
> (driver_probe_device+0x104/0x22c)
> [2.259988] [] (driver_probe_device) from []
> (bus_for_each_drv+0x44/0x8c)
> [2.269087] [] (bus_for_each_drv) from []
> (device_attach+0x74/0x8c)
> [2.277620] [] (device_attach) from []
> (bus_probe_device+0x88/0xb0)
> [2.286074] [] (bus_probe_device) from []
> (deferred_probe_work_func+0x60/0x90)
> [2.295611] [] (deferred_probe_work_func) from []
> (process_one_work+0x1b4/0x4bc)
> [2.305288] [] (process_one_work) from []
> (worker_thread+0x148/0x550)
> [2.313954] [] (worker_thread) from []
> (kthread+0xc8/0xe4)
> [2.321628] [] (kthread) from []
> (ret_from_fork+0x14/0x2c)
>
Sorry to miss that this was reported by Tony.
Reported-by: Tony Lindgren
cheers,
-roger
> Signed-off-by: Roger Quadros
> ---
> drivers/clk/ti/dpll.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
> index abd956d..79791e1 100644
> --- a/drivers/clk/ti/dpll.c
> +++ b/drivers/clk/ti/dpll.c
> @@ -161,7 +161,8 @@ cleanup:
> }
>
> #if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
> - defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM33XX)
> + defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM33XX) || \
> + defined(CONFIG_SOC_AM43XX)
> /**
> * ti_clk_register_dpll_x2 - Registers a DPLLx2 clock
> * @node: device node for this clock
> @@ -322,7 +323,7 @@ CLK_OF_DECLARE(ti_omap4_dpll_x2_clock,
> "ti,omap4-dpll-x2-clock",
> of_ti_omap4_dpll_x2_setup);
> #endif
>
> -#ifdef CONFIG_SOC_AM33XX
> +#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX)
> static void __init of_ti_am3_dpll_x2_setup(struct device_node *node)
> {
> ti_clk_register_dpll_x2(node, &dpll_x2_ck_ops, NULL);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/9] regulator: palmas: Add palmas_pmic_driver_data structure
> >>Add palmas_pmic_driver_data structure.
> >>
> >>Signed-off-by: Keerthy
> >>---
> >> include/linux/mfd/palmas.h | 25 +
> >> 1 file changed, 25 insertions(+)
> >>
> >>diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
> >>index 8d68452..70f0695 100644
> >>--- a/include/linux/mfd/palmas.h
> >>+++ b/include/linux/mfd/palmas.h
[...]
> >>+struct palmas_pmic_driver_data {
> >>+ int smps_start;
> >>+ int smps_end;
> >>+ int ldo_begin;
> >>+ int ldo_end;
> >>+ int max_reg;
> >>+ struct regs_info *palmas_regs_info;
> >>+ struct of_regulator_match *palmas_matches;
> >>+ struct palmas_sleep_requestor_info *sleep_req_info;
> >>+ int (*smps_register)(struct palmas_pmic *pmic,
> >>+struct palmas_pmic_driver_data *ddata,
> >>+struct palmas_pmic_platform_data *pdata,
> >>+const char *pdev_name,
> >>+struct regulator_config config);
> >>+ int (*ldo_register)(struct palmas_pmic *pmic,
> >>+ struct palmas_pmic_driver_data *ddata,
> >>+ struct palmas_pmic_platform_data *pdata,
> >>+ const char *pdev_name,
> >>+ struct regulator_config config);
> >Are you sure you need to store all of this stuff?
> >
> >Particularly the match pointer. Do you really re-use it?
>
> Match pointer is used extensively in the palmas_regulator.c.
> This structure is very much used by regulator driver.
On closer inspection, I now see that it's a 'of_regulator_match',
rather than an 'of_match' pointer, which were my initial thoughts. I
think it would have been weird to carry the 'of_match', but the
reality sounds sane.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
On Wed, 18 Jun 2014, Paul Walmsley wrote: > I don't disagree that some platforms might want this behavior. But it's > not a safe default, the flag should be the other way around. Rare is the > software engineer that knows whether the clock muxes on their platform are > glitchless. (beyond all the other issues with unexpected parent changes, races, etc.) - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
