[PATCH] ARM: dts: am437x-sk-evm.dts: fix LCD timings
The lcd0 node for am437x-sk-evm.dts contains bad LCD timings, and while
they seem to work with a quick test, doing for example blank/unblank
will give you a black display.
This patch updates the timings to the 'typical' values from the LCD spec
sheet.
Also, the compatible string is completely bogus, as
"osddisplays,osd057T0559-34ts" is _not_ a 480x272 panel. The panel on
the board is a newhaven one. Update the compatible string to reflect
this. Note that this hasn't caused any issues, as the "panel-dpi"
matches the driver.
Cc: # v3.17+
Tested-by: Felipe Balbi
Signed-off-by: Tomi Valkeinen
---
arch/arm/boot/dts/am437x-sk-evm.dts | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 859ff3d620ee..66071c7b3dde 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -100,7 +100,7 @@
};
lcd0: display {
- compatible = "osddisplays,osd057T0559-34ts", "panel-dpi";
+ compatible = "newhaven,nhd-4.3-480272ef-atxl", "panel-dpi";
label = "lcd";
pinctrl-names = "default";
@@ -112,11 +112,11 @@
clock-frequency = <900>;
hactive = <480>;
vactive = <272>;
- hfront-porch = <8>;
- hback-porch = <43>;
- hsync-len = <4>;
- vback-porch = <12>;
- vfront-porch = <4>;
+ hfront-porch = <2>;
+ hback-porch = <2>;
+ hsync-len = <41>;
+ vfront-porch = <2>;
+ vback-porch = <2>;
vsync-len = <10>;
hsync-active = <0>;
vsync-active = <0>;
--
2.2.0
--
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: FIX ME in omap-cpufreq.c
On 4 December 2014 at 23:13, nick wrote: > Greetings Kevin and the other maintainers of this file, Hi, > I am wondering why the below code still has a fix me? It seems rather trivial > to fix, as all we need is the transition > time of the CPU. Due to this and I don't have the hardware do any of you have > the hardware, can any of you tell me the > correct value for this if you have this hardware. Further more I will paste > the code below. Not every FIXME wants to get fixed. Believe me. Don't just grep for FIXME's in kernel and send patches for that. It isn't working anymore Nick. I understand that you want to get some name for yourself in the kernel community (and for sure there is nothing wrong in that), but the way you have chosen isn't taking you there. People aren't really happy with the way things are proceeding. If you really want to help kernel (and yourself), start getting deeper knowledge of frameworks you have any idea of. And they try to solve some real problems. I don't want to discourage you here, but trying to show the right path. Rest is upon you :) -- viresh -- 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] ARM: dts: am57xx-beagle-x15: Add dual ethernet
On 12/04/2014 03:02 PM, Felipe Balbi wrote:
> Add CPSW DT binding to beagle X15 DTS in order to
> get ethernet working with this board.
>
> Note that we're also adding sleep state which will
> place all pins in mux mode 15 - which means "driver
> off" - thus conserving power.
>
> Signed-off-by: Nishanth Menon
> Signed-off-by: Sekhar Nori
> Signed-off-by: Felipe Balbi
> ---
>
> Changes since v1:
> - removed duplicated SoB from myself
> - Fixed s/Slave 1/Slave2/ in one comment
> - slightly improved commit log
>
> arch/arm/boot/dts/am57xx-beagle-x15.dts | 106
>
> 1 file changed, 106 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 49edbda..6c2e8e4 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -140,6 +140,86 @@
> >;
> };
>
> + cpsw_pins_default: cpsw_pins_default {
> + pinctrl-single,pins = <
> + /* Slave 1 */
> + 0x250 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tclk */
> + 0x254 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tctl */
> + 0x258 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td3 */
> + 0x25c (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td2 */
> + 0x260 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td1 */
> + 0x264 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td0 */
> + 0x268 (PIN_INPUT | MUX_MODE0) /* rgmii1_rclk */
> + 0x26c (PIN_INPUT | MUX_MODE0) /* rgmii1_rctl */
> + 0x270 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd3 */
> + 0x274 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd2 */
> + 0x278 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd1 */
> + 0x27c (PIN_INPUT | MUX_MODE0) /* rgmii1_rd0 */
> +
> + /* Slave 2 */
> + 0x198 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tclk */
> + 0x19c (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tctl */
> + 0x1a0 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td3 */
> + 0x1a4 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td2 */
> + 0x1a8 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td1 */
> + 0x1ac (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td0 */
> + 0x1b0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rclk */
> + 0x1b4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rctl */
> + 0x1b8 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd3 */
> + 0x1bc (PIN_INPUT | MUX_MODE3) /* rgmii2_rd2 */
> + 0x1c0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd1 */
> + 0x1c4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd0 */
> + >;
> +
> + };
> +
> + cpsw_pins_sleep: cpsw_pins_sleep {
> + pinctrl-single,pins = <
> + /* Slave 1 */
> + 0x250 (PIN_INPUT | MUX_MODE15)
> + 0x254 (PIN_INPUT | MUX_MODE15)
> + 0x258 (PIN_INPUT | MUX_MODE15)
> + 0x25c (PIN_INPUT | MUX_MODE15)
> + 0x260 (PIN_INPUT | MUX_MODE15)
> + 0x264 (PIN_INPUT | MUX_MODE15)
> + 0x268 (PIN_INPUT | MUX_MODE15)
> + 0x26c (PIN_INPUT | MUX_MODE15)
> + 0x270 (PIN_INPUT | MUX_MODE15)
> + 0x274 (PIN_INPUT | MUX_MODE15)
> + 0x278 (PIN_INPUT | MUX_MODE15)
> + 0x27c (PIN_INPUT | MUX_MODE15)
> +
> + /* Slave 2 */
> + 0x198 (PIN_INPUT | MUX_MODE15)
> + 0x19c (PIN_INPUT | MUX_MODE15)
> + 0x1a0 (PIN_INPUT | MUX_MODE15)
> + 0x1a4 (PIN_INPUT | MUX_MODE15)
> + 0x1a8 (PIN_INPUT | MUX_MODE15)
> + 0x1ac (PIN_INPUT | MUX_MODE15)
> + 0x1b0 (PIN_INPUT | MUX_MODE15)
> + 0x1b4 (PIN_INPUT | MUX_MODE15)
> + 0x1b8 (PIN_INPUT | MUX_MODE15)
> + 0x1bc (PIN_INPUT | MUX_MODE15)
> + 0x1c0 (PIN_INPUT | MUX_MODE15)
> + 0x1c4 (PIN_INPUT | MUX_MODE15)
> + >;
> + };
> +
> + davinci_mdio_pins_default: davinci_mdio_pins_default {
> + pinctrl-single,pins = <
> + /* MDIO */
> + 0x23c (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_mclk */
> + 0x240 (PIN_INPUT_PULLUP | MUX_MODE0)/* mdio_d */
> + >;
> + };
> +
> + davinci_mdio_pins_sleep: davinci_mdio_pins_sleep {
> + pinctrl-single,pins = <
> + 0x23c (PIN_INPUT | MUX_MODE15)
> + 0x240 (PIN_INPUT | MUX_MODE15)
> + >;
> + };
Re: [PATCH] ARM: dts: Fix gpmc regression for omap 2430sdp smc91x
On 12/04/2014 03:04 PM, Tony Lindgren wrote:
> Commit f4d809ec55b6 ("ARM: dts: Fix gpmc timings for omap 2430sdp")
> added GPMC timings for 2430sdp. This however broke the Ethernet
> for some versions of u-boot using a different L3 clock frequency:
>
> set_gpmc_timing_reg: GPMC error! CS5: cs_rd_off: 233 ns, 39 ticks > 31
> omap-gpmc 6e00.gpmc: failed to set gpmc timings for: ethernet
>
> This is because the smsc91x timings from 1.1.4 u-boot overflow the
> GPMC registers when booted with 1.1.3 version of u-boot.
>
> Let's fix this issue by using the better timings from u-boot 1.1.3
> as they also work on 1.1.4 and are faster.
>
> Note that so far the attempts over the years to calculate the GPMC
> timings on the SDP boards have failed probably because of the
> unknown latencies added by the FPGA on the debug boards.
>
> Reported-by: Nishanth Menon
> Signed-off-by: Tony Lindgren
>
> --- a/arch/arm/boot/dts/omap2430-sdp.dts
> +++ b/arch/arm/boot/dts/omap2430-sdp.dts
> @@ -48,22 +48,22 @@
> gpmc,device-width = <1>;
> gpmc,cycle2cycle-samecsen = <1>;
> gpmc,cycle2cycle-diffcsen = <1>;
> - gpmc,cs-on-ns = <7>;
> - gpmc,cs-rd-off-ns = <233>;
> - gpmc,cs-wr-off-ns = <233>;
> - gpmc,adv-on-ns = <22>;
> - gpmc,adv-rd-off-ns = <60>;
> - gpmc,adv-wr-off-ns = <60>;
> - gpmc,oe-on-ns = <67>;
> - gpmc,oe-off-ns = <210>;
> - gpmc,we-on-ns = <67>;
> - gpmc,we-off-ns = <210>;
> - gpmc,rd-cycle-ns = <233>;
> - gpmc,wr-cycle-ns = <233>;
> - gpmc,access-ns = <233>;
> - gpmc,page-burst-access-ns = <30>;
> - gpmc,bus-turnaround-ns = <30>;
> - gpmc,cycle2cycle-delay-ns = <30>;
> + gpmc,cs-on-ns = <6>;
> + gpmc,cs-rd-off-ns = <187>;
> + gpmc,cs-wr-off-ns = <187>;
> + gpmc,adv-on-ns = <18>;
> + gpmc,adv-rd-off-ns = <48>;
> + gpmc,adv-wr-off-ns = <48>;
> + gpmc,oe-on-ns = <60>;
> + gpmc,oe-off-ns = <169>;
> + gpmc,we-on-ns = <66>;
> + gpmc,we-off-ns = <169>;
> + gpmc,rd-cycle-ns = <187>;
> + gpmc,wr-cycle-ns = <187>;
> + gpmc,access-ns = <187>;
> + gpmc,page-burst-access-ns = <24>;
> + gpmc,bus-turnaround-ns = <24>;
> + gpmc,cycle2cycle-delay-ns = <24>;
> gpmc,wait-monitoring-ns = <0>;
> gpmc,clk-activation-ns = <0>;
> gpmc,wr-data-mux-bus-ns = <0>;
>
Before (with gpmc debug): http://slexy.org/raw/s2bbhWNGxU
After:
http://slexy.org/raw/s20lY1YW65
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
Re: [PATCH v5 1/4] ARM: OMAP2+: Make sure pandora_wl1251_init_card() applies to SDIO only
* Doug Anderson [141202 15:45]:
> In preparation for having init_card() called for all card types (not
> just SDIO), change pandora_wl1251_init_card() so it checks whether the
> card type is SDIO.
Seems OK to me and should not conflict with linux-omap patches:
Acked-by: Tony Lindgren
> Signed-off-by: Doug Anderson
> ---
> Changes in v5:
> - Split fixup to pandora_wl1251_init_card() into its own patch.
>
> Changes in v3: None
> Changes in v2: None
>
> arch/arm/mach-omap2/board-omap3pandora.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
> b/arch/arm/mach-omap2/board-omap3pandora.c
> index 7f17087..969e100 100644
> --- a/arch/arm/mach-omap2/board-omap3pandora.c
> +++ b/arch/arm/mach-omap2/board-omap3pandora.c
> @@ -254,12 +254,14 @@ static void pandora_wl1251_init_card(struct mmc_card
> *card)
>* We have TI wl1251 attached to MMC3. Pass this information to
>* SDIO core because it can't be probed by normal methods.
>*/
> - card->quirks |= MMC_QUIRK_NONSTD_SDIO;
> - card->cccr.wide_bus = 1;
> - card->cis.vendor = 0x104c;
> - card->cis.device = 0x9066;
> - card->cis.blksize = 512;
> - card->cis.max_dtr = 2000;
> + if (card->type == MMC_TYPE_SDIO || card->type == MMC_TYPE_SD_COMBO) {
> + card->quirks |= MMC_QUIRK_NONSTD_SDIO;
> + card->cccr.wide_bus = 1;
> + card->cis.vendor = 0x104c;
> + card->cis.device = 0x9066;
> + card->cis.blksize = 512;
> + card->cis.max_dtr = 2000;
> + }
> }
>
> static struct omap2_hsmmc_info omap3pandora_mmc[] = {
> --
> 2.2.0.rc0.207.ga3a616c
>
--
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] ARM: dts: Fix gpmc regression for omap 2430sdp smc91x
Commit f4d809ec55b6 ("ARM: dts: Fix gpmc timings for omap 2430sdp")
added GPMC timings for 2430sdp. This however broke the Ethernet
for some versions of u-boot using a different L3 clock frequency:
set_gpmc_timing_reg: GPMC error! CS5: cs_rd_off: 233 ns, 39 ticks > 31
omap-gpmc 6e00.gpmc: failed to set gpmc timings for: ethernet
This is because the smsc91x timings from 1.1.4 u-boot overflow the
GPMC registers when booted with 1.1.3 version of u-boot.
Let's fix this issue by using the better timings from u-boot 1.1.3
as they also work on 1.1.4 and are faster.
Note that so far the attempts over the years to calculate the GPMC
timings on the SDP boards have failed probably because of the
unknown latencies added by the FPGA on the debug boards.
Reported-by: Nishanth Menon
Signed-off-by: Tony Lindgren
--- a/arch/arm/boot/dts/omap2430-sdp.dts
+++ b/arch/arm/boot/dts/omap2430-sdp.dts
@@ -48,22 +48,22 @@
gpmc,device-width = <1>;
gpmc,cycle2cycle-samecsen = <1>;
gpmc,cycle2cycle-diffcsen = <1>;
- gpmc,cs-on-ns = <7>;
- gpmc,cs-rd-off-ns = <233>;
- gpmc,cs-wr-off-ns = <233>;
- gpmc,adv-on-ns = <22>;
- gpmc,adv-rd-off-ns = <60>;
- gpmc,adv-wr-off-ns = <60>;
- gpmc,oe-on-ns = <67>;
- gpmc,oe-off-ns = <210>;
- gpmc,we-on-ns = <67>;
- gpmc,we-off-ns = <210>;
- gpmc,rd-cycle-ns = <233>;
- gpmc,wr-cycle-ns = <233>;
- gpmc,access-ns = <233>;
- gpmc,page-burst-access-ns = <30>;
- gpmc,bus-turnaround-ns = <30>;
- gpmc,cycle2cycle-delay-ns = <30>;
+ gpmc,cs-on-ns = <6>;
+ gpmc,cs-rd-off-ns = <187>;
+ gpmc,cs-wr-off-ns = <187>;
+ gpmc,adv-on-ns = <18>;
+ gpmc,adv-rd-off-ns = <48>;
+ gpmc,adv-wr-off-ns = <48>;
+ gpmc,oe-on-ns = <60>;
+ gpmc,oe-off-ns = <169>;
+ gpmc,we-on-ns = <66>;
+ gpmc,we-off-ns = <169>;
+ gpmc,rd-cycle-ns = <187>;
+ gpmc,wr-cycle-ns = <187>;
+ gpmc,access-ns = <187>;
+ gpmc,page-burst-access-ns = <24>;
+ gpmc,bus-turnaround-ns = <24>;
+ gpmc,cycle2cycle-delay-ns = <24>;
gpmc,wait-monitoring-ns = <0>;
gpmc,clk-activation-ns = <0>;
gpmc,wr-data-mux-bus-ns = <0>;
--
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] ARM: dts: am57xx-beagle-x15: Add dual ethernet
Add CPSW DT binding to beagle X15 DTS in order to
get ethernet working with this board.
Note that we're also adding sleep state which will
place all pins in mux mode 15 - which means "driver
off" - thus conserving power.
Signed-off-by: Nishanth Menon
Signed-off-by: Sekhar Nori
Signed-off-by: Felipe Balbi
---
Changes since v1:
- removed duplicated SoB from myself
- Fixed s/Slave 1/Slave2/ in one comment
- slightly improved commit log
arch/arm/boot/dts/am57xx-beagle-x15.dts | 106
1 file changed, 106 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..6c2e8e4 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -140,6 +140,86 @@
>;
};
+ cpsw_pins_default: cpsw_pins_default {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ 0x250 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tclk */
+ 0x254 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tctl */
+ 0x258 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td3 */
+ 0x25c (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td2 */
+ 0x260 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td1 */
+ 0x264 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td0 */
+ 0x268 (PIN_INPUT | MUX_MODE0) /* rgmii1_rclk */
+ 0x26c (PIN_INPUT | MUX_MODE0) /* rgmii1_rctl */
+ 0x270 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd3 */
+ 0x274 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd2 */
+ 0x278 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd1 */
+ 0x27c (PIN_INPUT | MUX_MODE0) /* rgmii1_rd0 */
+
+ /* Slave 2 */
+ 0x198 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tclk */
+ 0x19c (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tctl */
+ 0x1a0 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td3 */
+ 0x1a4 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td2 */
+ 0x1a8 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td1 */
+ 0x1ac (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td0 */
+ 0x1b0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rclk */
+ 0x1b4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rctl */
+ 0x1b8 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd3 */
+ 0x1bc (PIN_INPUT | MUX_MODE3) /* rgmii2_rd2 */
+ 0x1c0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd1 */
+ 0x1c4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd0 */
+ >;
+
+ };
+
+ cpsw_pins_sleep: cpsw_pins_sleep {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ 0x250 (PIN_INPUT | MUX_MODE15)
+ 0x254 (PIN_INPUT | MUX_MODE15)
+ 0x258 (PIN_INPUT | MUX_MODE15)
+ 0x25c (PIN_INPUT | MUX_MODE15)
+ 0x260 (PIN_INPUT | MUX_MODE15)
+ 0x264 (PIN_INPUT | MUX_MODE15)
+ 0x268 (PIN_INPUT | MUX_MODE15)
+ 0x26c (PIN_INPUT | MUX_MODE15)
+ 0x270 (PIN_INPUT | MUX_MODE15)
+ 0x274 (PIN_INPUT | MUX_MODE15)
+ 0x278 (PIN_INPUT | MUX_MODE15)
+ 0x27c (PIN_INPUT | MUX_MODE15)
+
+ /* Slave 2 */
+ 0x198 (PIN_INPUT | MUX_MODE15)
+ 0x19c (PIN_INPUT | MUX_MODE15)
+ 0x1a0 (PIN_INPUT | MUX_MODE15)
+ 0x1a4 (PIN_INPUT | MUX_MODE15)
+ 0x1a8 (PIN_INPUT | MUX_MODE15)
+ 0x1ac (PIN_INPUT | MUX_MODE15)
+ 0x1b0 (PIN_INPUT | MUX_MODE15)
+ 0x1b4 (PIN_INPUT | MUX_MODE15)
+ 0x1b8 (PIN_INPUT | MUX_MODE15)
+ 0x1bc (PIN_INPUT | MUX_MODE15)
+ 0x1c0 (PIN_INPUT | MUX_MODE15)
+ 0x1c4 (PIN_INPUT | MUX_MODE15)
+ >;
+ };
+
+ davinci_mdio_pins_default: davinci_mdio_pins_default {
+ pinctrl-single,pins = <
+ /* MDIO */
+ 0x23c (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_mclk */
+ 0x240 (PIN_INPUT_PULLUP | MUX_MODE0)/* mdio_d */
+ >;
+ };
+
+ davinci_mdio_pins_sleep: davinci_mdio_pins_sleep {
+ pinctrl-single,pins = <
+ 0x23c (PIN_INPUT | MUX_MODE15)
+ 0x240 (PIN_INPUT | MUX_MODE15)
+ >;
+ };
+
tps659038_pins_default: tps659038_pins_default {
pinctrl-single,pins = <
Re: [PATCH] ARM: dts: am57xx-beagle-x15: Add dual ethernet
On 12/04/2014 02:55 PM, Felipe Balbi wrote:
> On Thu, Dec 04, 2014 at 02:53:38PM -0600, Felipe Balbi wrote:
>> Make CPSW work - BeagleBoard-X15 has two network ports
>>
>> MUX_MODE15 means "driver off". Pins are turned off
>> conserving more power.
>>
>> Signed-off-by: Felipe Balbi
>> Signed-off-by: Nishanth Menon
>> Signed-off-by: Sekhar Nori
>> Signed-off-by: Felipe Balbi
>
> grrr, not sure why it signed again... I guess git cherry-pick -s isn't
> very smart after all. Tony, let me know if you prefer that I resend
> fixing this SoB detail. In any case:
>
> boot logs http://hastebin.com/joxiweleyi
>
>> ---
>> arch/arm/boot/dts/am57xx-beagle-x15.dts | 106
>>
>> 1 file changed, 106 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
>> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
>> index 49edbda..da1b24c 100644
>> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
>> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
>> @@ -140,6 +140,86 @@
>> >;
>> };
>>
>> +cpsw_pins_default: cpsw_pins_default {
>> +pinctrl-single,pins = <
>> +/* Slave 1 */
>> +0x250 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tclk */
>> +0x254 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tctl */
>> +0x258 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td3 */
>> +0x25c (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td2 */
>> +0x260 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td1 */
>> +0x264 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td0 */
>> +0x268 (PIN_INPUT | MUX_MODE0) /* rgmii1_rclk */
>> +0x26c (PIN_INPUT | MUX_MODE0) /* rgmii1_rctl */
>> +0x270 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd3 */
>> +0x274 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd2 */
>> +0x278 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd1 */
>> +0x27c (PIN_INPUT | MUX_MODE0) /* rgmii1_rd0 */
>> +
>> +/* Slave 2 */
>> +0x198 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tclk */
>> +0x19c (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tctl */
>> +0x1a0 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td3 */
>> +0x1a4 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td2 */
>> +0x1a8 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td1 */
>> +0x1ac (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td0 */
>> +0x1b0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rclk */
>> +0x1b4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rctl */
>> +0x1b8 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd3 */
>> +0x1bc (PIN_INPUT | MUX_MODE3) /* rgmii2_rd2 */
>> +0x1c0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd1 */
>> +0x1c4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd0 */
>> +>;
>> +
>> +};
>> +
>> +cpsw_pins_sleep: cpsw_pins_sleep {
>> +pinctrl-single,pins = <
>> +/* Slave 1 */
>> +0x250 (PIN_INPUT | MUX_MODE15)
>> +0x254 (PIN_INPUT | MUX_MODE15)
>> +0x258 (PIN_INPUT | MUX_MODE15)
>> +0x25c (PIN_INPUT | MUX_MODE15)
>> +0x260 (PIN_INPUT | MUX_MODE15)
>> +0x264 (PIN_INPUT | MUX_MODE15)
>> +0x268 (PIN_INPUT | MUX_MODE15)
>> +0x26c (PIN_INPUT | MUX_MODE15)
>> +0x270 (PIN_INPUT | MUX_MODE15)
>> +0x274 (PIN_INPUT | MUX_MODE15)
>> +0x278 (PIN_INPUT | MUX_MODE15)
>> +0x27c (PIN_INPUT | MUX_MODE15)
>> +
>> +/* Slave 1 */
Slave 2?
>> +0x198 (PIN_INPUT | MUX_MODE15)
>> +0x19c (PIN_INPUT | MUX_MODE15)
>> +0x1a0 (PIN_INPUT | MUX_MODE15)
>> +0x1a4 (PIN_INPUT | MUX_MODE15)
>> +0x1a8 (PIN_INPUT | MUX_MODE15)
>> +0x1ac (PIN_INPUT | MUX_MODE15)
>> +0x1b0 (PIN_INPUT | MUX_MODE15)
>> +0x1b4 (PIN_INPUT | MUX_MODE15)
>> +0x1b8 (PIN_INPUT | MUX_MODE15)
>> +0x1bc (PIN_INPUT | MUX_MODE15)
>> +0x1c0 (PIN_INPUT | MUX_MODE15)
>> +0x1c4 (PIN_INPUT | MUX_MODE15)
>> +>;
>> +};
>> +
>> +davinci_mdio_pins_default: davinci_mdio_pins_default {
>> +pinctrl-single,pins = <
>> +/* MDIO */
>> +0x23c (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_mclk */
>> +0x240 (PIN_INPUT_PULLUP | MUX_MODE0)/* mdio_d */
>> +>;
>> +};
>> +
>> +davinci_mdio_pins_sleep: davinci_mdio_pins_sleep {
>> +pinctrl-single,pins = <
>> +0x23c
Re: [PATCH] ARM: dts: am57xx-beagle-x15: Add dual ethernet
On Thu, Dec 04, 2014 at 02:53:38PM -0600, Felipe Balbi wrote:
> Make CPSW work - BeagleBoard-X15 has two network ports
>
> MUX_MODE15 means "driver off". Pins are turned off
> conserving more power.
>
> Signed-off-by: Felipe Balbi
> Signed-off-by: Nishanth Menon
> Signed-off-by: Sekhar Nori
> Signed-off-by: Felipe Balbi
grrr, not sure why it signed again... I guess git cherry-pick -s isn't
very smart after all. Tony, let me know if you prefer that I resend
fixing this SoB detail. In any case:
boot logs http://hastebin.com/joxiweleyi
> ---
> arch/arm/boot/dts/am57xx-beagle-x15.dts | 106
>
> 1 file changed, 106 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> index 49edbda..da1b24c 100644
> --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
> +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
> @@ -140,6 +140,86 @@
> >;
> };
>
> + cpsw_pins_default: cpsw_pins_default {
> + pinctrl-single,pins = <
> + /* Slave 1 */
> + 0x250 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tclk */
> + 0x254 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tctl */
> + 0x258 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td3 */
> + 0x25c (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td2 */
> + 0x260 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td1 */
> + 0x264 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td0 */
> + 0x268 (PIN_INPUT | MUX_MODE0) /* rgmii1_rclk */
> + 0x26c (PIN_INPUT | MUX_MODE0) /* rgmii1_rctl */
> + 0x270 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd3 */
> + 0x274 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd2 */
> + 0x278 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd1 */
> + 0x27c (PIN_INPUT | MUX_MODE0) /* rgmii1_rd0 */
> +
> + /* Slave 2 */
> + 0x198 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tclk */
> + 0x19c (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tctl */
> + 0x1a0 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td3 */
> + 0x1a4 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td2 */
> + 0x1a8 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td1 */
> + 0x1ac (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td0 */
> + 0x1b0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rclk */
> + 0x1b4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rctl */
> + 0x1b8 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd3 */
> + 0x1bc (PIN_INPUT | MUX_MODE3) /* rgmii2_rd2 */
> + 0x1c0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd1 */
> + 0x1c4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd0 */
> + >;
> +
> + };
> +
> + cpsw_pins_sleep: cpsw_pins_sleep {
> + pinctrl-single,pins = <
> + /* Slave 1 */
> + 0x250 (PIN_INPUT | MUX_MODE15)
> + 0x254 (PIN_INPUT | MUX_MODE15)
> + 0x258 (PIN_INPUT | MUX_MODE15)
> + 0x25c (PIN_INPUT | MUX_MODE15)
> + 0x260 (PIN_INPUT | MUX_MODE15)
> + 0x264 (PIN_INPUT | MUX_MODE15)
> + 0x268 (PIN_INPUT | MUX_MODE15)
> + 0x26c (PIN_INPUT | MUX_MODE15)
> + 0x270 (PIN_INPUT | MUX_MODE15)
> + 0x274 (PIN_INPUT | MUX_MODE15)
> + 0x278 (PIN_INPUT | MUX_MODE15)
> + 0x27c (PIN_INPUT | MUX_MODE15)
> +
> + /* Slave 1 */
> + 0x198 (PIN_INPUT | MUX_MODE15)
> + 0x19c (PIN_INPUT | MUX_MODE15)
> + 0x1a0 (PIN_INPUT | MUX_MODE15)
> + 0x1a4 (PIN_INPUT | MUX_MODE15)
> + 0x1a8 (PIN_INPUT | MUX_MODE15)
> + 0x1ac (PIN_INPUT | MUX_MODE15)
> + 0x1b0 (PIN_INPUT | MUX_MODE15)
> + 0x1b4 (PIN_INPUT | MUX_MODE15)
> + 0x1b8 (PIN_INPUT | MUX_MODE15)
> + 0x1bc (PIN_INPUT | MUX_MODE15)
> + 0x1c0 (PIN_INPUT | MUX_MODE15)
> + 0x1c4 (PIN_INPUT | MUX_MODE15)
> + >;
> + };
> +
> + davinci_mdio_pins_default: davinci_mdio_pins_default {
> + pinctrl-single,pins = <
> + /* MDIO */
> + 0x23c (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_mclk */
> + 0x240 (PIN_INPUT_PULLUP | MUX_MODE0)/* mdio_d */
> + >;
> + };
> +
> + davinci_mdio_pins_sleep: davinci_mdio_pins_sleep {
> + pinctrl-single,pins = <
> + 0x23c (PIN_INPUT | MUX_MODE15)
> + 0x240 (PIN_INPUT | MUX_MODE15)
> +
[PATCH] ARM: dts: am57xx-beagle-x15: Add dual ethernet
Make CPSW work - BeagleBoard-X15 has two network ports
MUX_MODE15 means "driver off". Pins are turned off
conserving more power.
Signed-off-by: Felipe Balbi
Signed-off-by: Nishanth Menon
Signed-off-by: Sekhar Nori
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 106
1 file changed, 106 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 49edbda..da1b24c 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -140,6 +140,86 @@
>;
};
+ cpsw_pins_default: cpsw_pins_default {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ 0x250 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tclk */
+ 0x254 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_tctl */
+ 0x258 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td3 */
+ 0x25c (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td2 */
+ 0x260 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td1 */
+ 0x264 (PIN_OUTPUT | MUX_MODE0) /* rgmii1_td0 */
+ 0x268 (PIN_INPUT | MUX_MODE0) /* rgmii1_rclk */
+ 0x26c (PIN_INPUT | MUX_MODE0) /* rgmii1_rctl */
+ 0x270 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd3 */
+ 0x274 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd2 */
+ 0x278 (PIN_INPUT | MUX_MODE0) /* rgmii1_rd1 */
+ 0x27c (PIN_INPUT | MUX_MODE0) /* rgmii1_rd0 */
+
+ /* Slave 2 */
+ 0x198 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tclk */
+ 0x19c (PIN_OUTPUT | MUX_MODE3) /* rgmii2_tctl */
+ 0x1a0 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td3 */
+ 0x1a4 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td2 */
+ 0x1a8 (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td1 */
+ 0x1ac (PIN_OUTPUT | MUX_MODE3) /* rgmii2_td0 */
+ 0x1b0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rclk */
+ 0x1b4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rctl */
+ 0x1b8 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd3 */
+ 0x1bc (PIN_INPUT | MUX_MODE3) /* rgmii2_rd2 */
+ 0x1c0 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd1 */
+ 0x1c4 (PIN_INPUT | MUX_MODE3) /* rgmii2_rd0 */
+ >;
+
+ };
+
+ cpsw_pins_sleep: cpsw_pins_sleep {
+ pinctrl-single,pins = <
+ /* Slave 1 */
+ 0x250 (PIN_INPUT | MUX_MODE15)
+ 0x254 (PIN_INPUT | MUX_MODE15)
+ 0x258 (PIN_INPUT | MUX_MODE15)
+ 0x25c (PIN_INPUT | MUX_MODE15)
+ 0x260 (PIN_INPUT | MUX_MODE15)
+ 0x264 (PIN_INPUT | MUX_MODE15)
+ 0x268 (PIN_INPUT | MUX_MODE15)
+ 0x26c (PIN_INPUT | MUX_MODE15)
+ 0x270 (PIN_INPUT | MUX_MODE15)
+ 0x274 (PIN_INPUT | MUX_MODE15)
+ 0x278 (PIN_INPUT | MUX_MODE15)
+ 0x27c (PIN_INPUT | MUX_MODE15)
+
+ /* Slave 1 */
+ 0x198 (PIN_INPUT | MUX_MODE15)
+ 0x19c (PIN_INPUT | MUX_MODE15)
+ 0x1a0 (PIN_INPUT | MUX_MODE15)
+ 0x1a4 (PIN_INPUT | MUX_MODE15)
+ 0x1a8 (PIN_INPUT | MUX_MODE15)
+ 0x1ac (PIN_INPUT | MUX_MODE15)
+ 0x1b0 (PIN_INPUT | MUX_MODE15)
+ 0x1b4 (PIN_INPUT | MUX_MODE15)
+ 0x1b8 (PIN_INPUT | MUX_MODE15)
+ 0x1bc (PIN_INPUT | MUX_MODE15)
+ 0x1c0 (PIN_INPUT | MUX_MODE15)
+ 0x1c4 (PIN_INPUT | MUX_MODE15)
+ >;
+ };
+
+ davinci_mdio_pins_default: davinci_mdio_pins_default {
+ pinctrl-single,pins = <
+ /* MDIO */
+ 0x23c (PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_mclk */
+ 0x240 (PIN_INPUT_PULLUP | MUX_MODE0)/* mdio_d */
+ >;
+ };
+
+ davinci_mdio_pins_sleep: davinci_mdio_pins_sleep {
+ pinctrl-single,pins = <
+ 0x23c (PIN_INPUT | MUX_MODE15)
+ 0x240 (PIN_INPUT | MUX_MODE15)
+ >;
+ };
+
tps659038_pins_default: tps659038_pins_default {
pinctrl-single,pins = <
0x418 (PIN_INPUT_PULLUP | MUX_MODE14) /*
wakeup0.gpio1_0 */
@@ -365,6 +445,32 @@
pinctrl-0 = <&uart3_pins_default>;
};
+&mac {
+ status = "okay";
+ pinctrl-names = "default"
Re: [PATCH v3 0/2] Add DRA7xx CPSW Ethernet support in Device Tree
On Thu, Nov 06, 2014 at 10:33:42PM +0530, Mugunthan V N wrote: > Tony > > On Monday 03 November 2014 09:57 PM, Felipe Balbi wrote: > > On Tue, Oct 21, 2014 at 12:22:23PM -0500, Nishanth Menon wrote: > >> On 15:37-20141021, Mugunthan V N wrote: > >>> Nishanth > >>> > >>> On Tuesday 21 October 2014 03:30 PM, Mugunthan V N wrote: > Adding device tree entry for CPSW to make it work in Dual EMAC mode. > These patches were tested with DRA7 hwmod patches on top of linux-next. > Patches are tested on top of Nishanth's PM tree for v3.17 [1] and pushed > my tree to [2]. > > Did a boot test with CPSW and ping test with suspend/resume, the boot > logs > on DRA7xx EVM are posted at [3] > > [1] git://github.com/nmenon/linux-2.6-playground.git > testing/v3.17/cpu-idle-suspend-dra7-omap5-framework > [2] git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git > v3.17/dra7-evm-cpsw-v3 > [3] http://pastebin.ubuntu.com/8613072/ > > Changes from v2: > * Changed pinctrl comments to hold mode0-name.mode-selected-name > * Changes slave numbers in the pinctrl comments > * Added cpsw and cpts clocks > > >>> > >>> I have not added support for dra72x-evm as it has only slave no 2 pinned > >>> out and having issues with bringing up the interface, need some more > >>> time to submit the patch, in the mean time I have submitted dra7-evm > >>> support only so that people can use dra7-evm on linux-next. > >> > >> Quickly tested as well: > >> http://slexy.org/raw/s2vISJxYrR > >> > >> Please feel free to add: > >> Tested-by: Nishanth Menon > >> Acked-by: Nishanth Menon > > > > I've used these patches with X15 (DRA7xx-based yet-to-be-released board) > > with v3.18-rc2. > > > > Tested-by: Felipe Balbi > > > > Ping on this another ping on this -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 0/2] Add DRA7xx CPSW Ethernet support in Device Tree
On Thu, Dec 04, 2014 at 02:14:01PM -0600, Felipe Balbi wrote: > On Thu, Nov 06, 2014 at 10:33:42PM +0530, Mugunthan V N wrote: > > Tony > > > > On Monday 03 November 2014 09:57 PM, Felipe Balbi wrote: > > > On Tue, Oct 21, 2014 at 12:22:23PM -0500, Nishanth Menon wrote: > > >> On 15:37-20141021, Mugunthan V N wrote: > > >>> Nishanth > > >>> > > >>> On Tuesday 21 October 2014 03:30 PM, Mugunthan V N wrote: > > Adding device tree entry for CPSW to make it work in Dual EMAC mode. > > These patches were tested with DRA7 hwmod patches on top of linux-next. > > Patches are tested on top of Nishanth's PM tree for v3.17 [1] and > > pushed > > my tree to [2]. > > > > Did a boot test with CPSW and ping test with suspend/resume, the boot > > logs > > on DRA7xx EVM are posted at [3] > > > > [1] git://github.com/nmenon/linux-2.6-playground.git > > testing/v3.17/cpu-idle-suspend-dra7-omap5-framework > > [2] git://git.ti.com/~mugunthanvnm/ti-linux-kernel/linux.git > > v3.17/dra7-evm-cpsw-v3 > > [3] http://pastebin.ubuntu.com/8613072/ > > > > Changes from v2: > > * Changed pinctrl comments to hold mode0-name.mode-selected-name > > * Changes slave numbers in the pinctrl comments > > * Added cpsw and cpts clocks > > > > >>> > > >>> I have not added support for dra72x-evm as it has only slave no 2 pinned > > >>> out and having issues with bringing up the interface, need some more > > >>> time to submit the patch, in the mean time I have submitted dra7-evm > > >>> support only so that people can use dra7-evm on linux-next. > > >> > > >> Quickly tested as well: > > >> http://slexy.org/raw/s2vISJxYrR > > >> > > >> Please feel free to add: > > >> Tested-by: Nishanth Menon > > >> Acked-by: Nishanth Menon > > > > > > I've used these patches with X15 (DRA7xx-based yet-to-be-released board) > > > with v3.18-rc2. > > > > > > Tested-by: Felipe Balbi > > > > > > > Ping on this > > another ping on this oh my bad, it's already queued for v3.19. sorry -- balbi signature.asc Description: Digital signature
Re: [PATCH] hwmon: (gpio-fan) Allow usage of gpio operations that may sleep
On Thu, Dec 04, 2014 at 01:46:15PM -0600, Nishanth Menon wrote: > On 11:05-20141204, Guenter Roeck wrote: > > On Thu, Dec 04, 2014 at 10:58:47AM -0600, Nishanth Menon wrote: > > > Certain I2C based GPIO expanders could be used in sleepable context, > > > this results in: > > > [ 115.890569] [ cut here ] > > > [ 115.895422] WARNING: CPU: 0 PID: 1115 at drivers/gpio/gpiolib.c:1370 > > > gpiod_set_raw_value+0x40/0x4c() > > > [ 115.905024] Modules linked in: > > > [ 115.908229] CPU: 0 PID: 1115 Comm: sh Tainted: GW > > > 3.18.0-rc7-next-20141203-dirty #1 > > > [ 115.917461] Hardware name: Generic DRA74X (Flattened Device Tree) > > > [ 115.923876] [] (unwind_backtrace) from [] > > > (show_stack+0x10/0x14) > > > [ 115.932013] [] (show_stack) from [] > > > (dump_stack+0x78/0x94) > > > [ 115.939594] [] (dump_stack) from [] > > > (warn_slowpath_common+0x7c/0xb4) > > > [ 115.948094] [] (warn_slowpath_common) from [] > > > (warn_slowpath_null+0x1c/0x24) > > > [ 115.957315] [] (warn_slowpath_null) from [] > > > (gpiod_set_raw_value+0x40/0x4c) > > > [ 115.966457] [] (gpiod_set_raw_value) from [] > > > (set_fan_speed+0x4c/0x64) > > > [ 115.975145] [] (set_fan_speed) from [] > > > (set_rpm+0x98/0xac) > > > [ 115.982742] [] (set_rpm) from [] > > > (dev_attr_store+0x18/0x24) > > > [ 115.990426] [] (dev_attr_store) from [] > > > (sysfs_kf_write+0x4c/0x50) > > > [ 115.998742] [] (sysfs_kf_write) from [] > > > (kernfs_fop_write+0xbc/0x19c) > > > [ 116.007333] [] (kernfs_fop_write) from [] > > > (vfs_write+0xb0/0x1a0) > > > [ 116.015461] [] (vfs_write) from [] > > > (SyS_write+0x44/0x84) > > > [ 116.022881] [] (SyS_write) from [] > > > (ret_fast_syscall+0x0/0x48) > > > [ 116.030833] ---[ end trace 3a0b636123acab82 ]--- > > > > > > So, switch over to sleepable GPIO operations as there is no mandatory > > > need for non-sleepable gpio operations in the fan driver. > > > > > > This allows the fan driver to be used with i2c based gpio expanders such > > > as palmas_gpio. > > > > > > Signed-off-by: Nishanth Menon > > > > Applied to hwmon-next. Do we need this in older kernels ? > > I have'nt had a need for it till recently.. in terms of the sleepable > get/set, it seems to have been introduced with > commit 7560fa60fcdcdb0da662f6a9fad9064b554ef46c > Author: David Brownell > Date: Tue Mar 4 14:28:27 2008 -0800 > gpio: and "no GPIO support here" stubs > > Guessing no one needed it so far.. so probably future should be good > enough, I think.. > Ok. We can still add it to -stable at a later time if the need arises. Guenter -- 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] hwmon: (gpio-fan) Allow usage of gpio operations that may sleep
On 11:05-20141204, Guenter Roeck wrote: > On Thu, Dec 04, 2014 at 10:58:47AM -0600, Nishanth Menon wrote: > > Certain I2C based GPIO expanders could be used in sleepable context, > > this results in: > > [ 115.890569] [ cut here ] > > [ 115.895422] WARNING: CPU: 0 PID: 1115 at drivers/gpio/gpiolib.c:1370 > > gpiod_set_raw_value+0x40/0x4c() > > [ 115.905024] Modules linked in: > > [ 115.908229] CPU: 0 PID: 1115 Comm: sh Tainted: GW > > 3.18.0-rc7-next-20141203-dirty #1 > > [ 115.917461] Hardware name: Generic DRA74X (Flattened Device Tree) > > [ 115.923876] [] (unwind_backtrace) from [] > > (show_stack+0x10/0x14) > > [ 115.932013] [] (show_stack) from [] > > (dump_stack+0x78/0x94) > > [ 115.939594] [] (dump_stack) from [] > > (warn_slowpath_common+0x7c/0xb4) > > [ 115.948094] [] (warn_slowpath_common) from [] > > (warn_slowpath_null+0x1c/0x24) > > [ 115.957315] [] (warn_slowpath_null) from [] > > (gpiod_set_raw_value+0x40/0x4c) > > [ 115.966457] [] (gpiod_set_raw_value) from [] > > (set_fan_speed+0x4c/0x64) > > [ 115.975145] [] (set_fan_speed) from [] > > (set_rpm+0x98/0xac) > > [ 115.982742] [] (set_rpm) from [] > > (dev_attr_store+0x18/0x24) > > [ 115.990426] [] (dev_attr_store) from [] > > (sysfs_kf_write+0x4c/0x50) > > [ 115.998742] [] (sysfs_kf_write) from [] > > (kernfs_fop_write+0xbc/0x19c) > > [ 116.007333] [] (kernfs_fop_write) from [] > > (vfs_write+0xb0/0x1a0) > > [ 116.015461] [] (vfs_write) from [] > > (SyS_write+0x44/0x84) > > [ 116.022881] [] (SyS_write) from [] > > (ret_fast_syscall+0x0/0x48) > > [ 116.030833] ---[ end trace 3a0b636123acab82 ]--- > > > > So, switch over to sleepable GPIO operations as there is no mandatory > > need for non-sleepable gpio operations in the fan driver. > > > > This allows the fan driver to be used with i2c based gpio expanders such > > as palmas_gpio. > > > > Signed-off-by: Nishanth Menon > > Applied to hwmon-next. Do we need this in older kernels ? I have'nt had a need for it till recently.. in terms of the sleepable get/set, it seems to have been introduced with commit 7560fa60fcdcdb0da662f6a9fad9064b554ef46c Author: David Brownell Date: Tue Mar 4 14:28:27 2008 -0800 gpio: and "no GPIO support here" stubs Guessing no one needed it so far.. so probably future should be good enough, I think.. -- 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] hwmon: (gpio-fan) Allow usage of gpio operations that may sleep
On Thu, Dec 04, 2014 at 10:58:47AM -0600, Nishanth Menon wrote: > Certain I2C based GPIO expanders could be used in sleepable context, > this results in: > [ 115.890569] [ cut here ] > [ 115.895422] WARNING: CPU: 0 PID: 1115 at drivers/gpio/gpiolib.c:1370 > gpiod_set_raw_value+0x40/0x4c() > [ 115.905024] Modules linked in: > [ 115.908229] CPU: 0 PID: 1115 Comm: sh Tainted: GW > 3.18.0-rc7-next-20141203-dirty #1 > [ 115.917461] Hardware name: Generic DRA74X (Flattened Device Tree) > [ 115.923876] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 115.932013] [] (show_stack) from [] > (dump_stack+0x78/0x94) > [ 115.939594] [] (dump_stack) from [] > (warn_slowpath_common+0x7c/0xb4) > [ 115.948094] [] (warn_slowpath_common) from [] > (warn_slowpath_null+0x1c/0x24) > [ 115.957315] [] (warn_slowpath_null) from [] > (gpiod_set_raw_value+0x40/0x4c) > [ 115.966457] [] (gpiod_set_raw_value) from [] > (set_fan_speed+0x4c/0x64) > [ 115.975145] [] (set_fan_speed) from [] > (set_rpm+0x98/0xac) > [ 115.982742] [] (set_rpm) from [] > (dev_attr_store+0x18/0x24) > [ 115.990426] [] (dev_attr_store) from [] > (sysfs_kf_write+0x4c/0x50) > [ 115.998742] [] (sysfs_kf_write) from [] > (kernfs_fop_write+0xbc/0x19c) > [ 116.007333] [] (kernfs_fop_write) from [] > (vfs_write+0xb0/0x1a0) > [ 116.015461] [] (vfs_write) from [] > (SyS_write+0x44/0x84) > [ 116.022881] [] (SyS_write) from [] > (ret_fast_syscall+0x0/0x48) > [ 116.030833] ---[ end trace 3a0b636123acab82 ]--- > > So, switch over to sleepable GPIO operations as there is no mandatory > need for non-sleepable gpio operations in the fan driver. > > This allows the fan driver to be used with i2c based gpio expanders such > as palmas_gpio. > > Signed-off-by: Nishanth Menon Applied to hwmon-next. Do we need this in older kernels ? Thanks, Guenter -- 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] hwmon: (gpio-fan) Add a shutdown handler to poweroff the fans
On Thu, Dec 04, 2014 at 10:58:56AM -0600, Nishanth Menon wrote: > Poweroff the fans when shutting down the system. Else, > echo '1' > /sys/class/hwmon/hwmon0/fan1_target; poweroff leaves the > fan running if the System power off does not drive the gpio expander > which might control the fan power supply. > > Signed-off-by: Nishanth Menon > --- Applied to hwmon-next. Thanks, Guenter -- 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Thursday 04 December 2014 19:40:34 Tony Lindgren wrote: > * Pali Rohár [141204 10:36]: > > see last mail in thread (I CCed you): > > "[PATCH] ARM: /proc/cpuinfo: Use DT machine name when > > possible" > > > > There is already some layer for converting ATAGs to DTB and > > it is in decompresser: > > arch/arm/boot/compressed/atags_to_fdt.c > > > > I do not know if it can help us to provide /proc/cpuinfo and > > /proc/atags in DT boot, but at least this this transfer > > cmdline and mem ATAGs to DBT. > > Yes that makes sense to me. Sorry forgot about that piece of > code as I have not tinkered with arch/arm/boot/compressed/* > for a few years. > I did not know about that code in compressed too... > It sounds like there may be some regression also if the > cmdline is not being passed like it already should. But I > assume you already figured that out and have some patches > coming :) > > Regards, > > Tony I did not start find out why it not working (do not have time now), but at least I know where to start looking for it. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Pali Rohár [141204 10:36]: > > see last mail in thread (I CCed you): > "[PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible" > > There is already some layer for converting ATAGs to DTB and it is > in decompresser: arch/arm/boot/compressed/atags_to_fdt.c > > I do not know if it can help us to provide /proc/cpuinfo and > /proc/atags in DT boot, but at least this this transfer cmdline > and mem ATAGs to DBT. Yes that makes sense to me. Sorry forgot about that piece of code as I have not tinkered with arch/arm/boot/compressed/* for a few years. It sounds like there may be some regression also if the cmdline is not being passed like it already should. But I assume you already figured that out and have some patches coming :) Regards, Tony -- 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] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Friday 28 November 2014 23:24:26 Tony Lindgren wrote: > * Pali Rohár [141128 13:43]: > > On Friday 28 November 2014 21:27:19 Tony Lindgren wrote: > > > Are you saying there are some issues with that? > > > > uboot (in mode when is loaded from NOLO) has those issues: > > > > 1) uboot cannot read n900 onenand mtd (uboot onenand driver > > not working, do not know why) > > 2) missing support for battery charging (can totally > > discharge battery) > > 3) missing support for panel panel (so sometimes screen is > > totally black until kernel is booted and loaded own drivers) > > 4) limit for storing both uboot and kernel into MTD is > > limited by 2MB (size of kernel nand partition) > > > > Basically you can use uboot if you accept all above issues. > > > > But there are people (Pavel CCed) who prefer to work without > > uboot when testing kernel. So it is not good idea to lock > > new kernel versions to depends on new uboot version. > > OK thanks for the update, I was not aware of the issues above. > > > > Are there other ATAGs needed beyond the ATAG_REVISION? > > > > Sorry for longer email. I will provide some more info about > > it. First I will describe that informations are passed from > > NOLO to kernel. Note that all those informations are passed > > also from uboot to kernel (uboot just reuse non static data > > from NOLO). Then I will describe that we need in userspace. > > > Here are all ATAGs from NOLO: > ... > > These we should not need, it's all coming from the .dts files. > > > 0036 - 0003:54410007 ATAG REVISION revision=2204 > > > >0588 - 000c:4f80 BOOTREASON: pwr_key > >0604 - 0018:4f82 VERSION: product = RX-51 > >0632 - 0018:4f82 VERSION: hw-build = 2204 > >0660 - 0018:4f82 VERSION: nolo = 1.4.14 > >0688 - 0018:4f82 VERSION: boot-mode= normal > > Seems like these are the ones we should somehow get. The > others should be coming in the .dts file already, or can be > deciphered based on the above in the kernel. > > > ATAG MEM is generated by NOLO and also uboot at runtime. But > > we have hardcoded memory values in n900 DT file. Maybe we > > should use those generated by uboot bootloader (or reuse > > uboot code for generating) instead using hardcoded one? > > Yes we should not need ATAG MEM. > > > ATAG REVISION is that which is magically generated by NOLO > > and which we want to reuse. Better would be understand how > > and why it NOLO generate (maybe there is something secret > > register which can tell it?). But I was not able to find > > out it. > > I would assume that's also somewhere in the cal area. > > > OMAP table is one big ATAG structure which contains lot of > > other values. Basically all values (except uart, bootreason > > and version) are static and on all n900 devices are same. > > > > Partitions are generated by NOLO from CAL (/dev/mtd1) data, > > but I think nobody ever changed them (but it is possible!). > > AFAIK it's safe to assume they are coming in the .dts file. > > > Uart is enabled when serial console is enabled via NOLO. > > We can keep the UART enabled all the time no problem. It's > timeouts just need to be configured for idle. > > > Bootreason contains omap3 bootreason value from special > > register (plus magic from NOLO) which is cleared > > automatically by NOLO (so no way to read it from kernel). > > > > Version contains some key-value data. Product is always > > RX-51, hw-build is same as ATAG REVISION, nolo is nolo > > version and value for boot-mode is ether normal or update. > > OK > > > What we need in userspace: > > > > In file /proc/cpuinfo: > > Hardware: Nokia RX-51 board > > Revision: > > > > And in any file and any format (does not matter if text, > > binary, whatever...) we need value from bootreason, > > boot-mode (and maybe nolo version). > > OK > > > Current maemo applications are using files /proc/bootreason > > (for bootreason) and /proc/component_version (for all > > version) which are specific for Nokia 2.6.28 kernel. All > > those applications (which reading ether bootreason or > > bootmode proc files) are either shell scripts or open > > source, so editing them is possible. I will start fixing > > them once there will be *stable* ABI for those data. > > > > With non DT (legacy) boot all above atags are present in > > binary file /proc/atags. > > > > But because DT boot does not provide /proc/atags file I need > > some interface how to read above needed strings. > > > > So I would like to know what is possible and how? > > How about patch things so we see /proc/atags also for DT based > booting, but in a way where the ATAGs don't do anything? > > > Does kernel provide some interface for telling userspace > > applications something like bootreason (e.g power key, > > software reset, rtc alarm, charger connected, ...)? > > I don't think we have anything like that currently. > > Regards, > > Tony Hi Ton
Re: [RFC 0/5] i2c: omap: new fixes 2
* Alexander Kochetkov [141203 06:36]: > This pacth series intended for fixing problem reported > by Tony Lindgren here[1] > > One of first four patched could fix the problem. > Last patch provide event trace so I could resolve problem. > It could be applied using 'git am' or 'patch -p1 ...' > > Patches are rebased on branch 'i2c/for-next' of > git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux > (6e79807443cba7397cd855ed29d6faba51d4c893) > > Tony, could you check, does the series fix the problem reported[1]? > If yes, could you bisect and point commit that solve. > If no, could you provide trace output (with or without the patches > from series). > If no, could you check does i2c-omap.c from commit > ca1f8da9ac5ce6e63d8f6933f83fabc1f3f961f4. > (the commit before my changes to kernel) work for you? It seems this is not related to your patches. Applying these cause the following though on my 2430sdp: omap_i2c 48072000.i2c: addr: 0x004b, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: XFER0: STAT=0x; IE=0x601f; CON=0x8000; (omap_i2c_xfer_msg:705) omap_i2c 48072000.i2c: XFER1: STAT=0x0010; IE=0x601f; CON=0x8600; (omap_i2c_xfer_msg:707) omap_i2c 48072000.i2c: THR: STAT=0x1410; IE=0x601f; CON=0x8600; (omap_i2c_isr_thread:1016) omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: THR: STAT=0x1000; IE=0x601f; CON=0x8600; (omap_i2c_isr_thread:1016) omap_i2c 48072000.i2c: THR DONE: STAT=0x1004; IE=0x601f; CON=0x8600; (omap_i2c_isr_thread:1168) omap_i2c 48072000.i2c: THR: STAT=0x1004; IE=0x601f; CON=0x8600; (omap_i2c_isr_thread:1016) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: THR: STAT=0x1000; IE=0x601f; CON=0x8602; (omap_i2c_isr_thread:1016) omap_i2c 48072000.i2c: THR DONE: STAT=0x1000; IE=0x601f; CON=0x8602; (omap_i2c_isr_thread:1168) omap_i2c 48072000.i2c: XFER TIMEOUT: STAT=0x1000; IE=0x601f; CON=0x8602; (omap_i2c_xfer_msg:716) omap_i2c 48072000.i2c: controller timed out twl: Write failed (mod 3, reg 0x0e count 1) Regards, Tony > [1] http://www.spinics.net/lists/linux-i2c/msg17811.html > > Alexander Kochetkov (5): > i2c: omap: ack only reported events > i2c: omap: simplify i462 errata handling for NACK and AL cases > i2c: omap: move STP generation logic into ISR thread > i2c: omap: reimpelement STP hack via 2-phases transfer > i2c: omap: add trace > > drivers/i2c/busses/i2c-omap.c | 162 > - > 1 file changed, 95 insertions(+), 67 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
Re: [RFC 1/2] i2c: omap: fix buffer overruns during RX/TX data processing
* Alexander Kochetkov [141202 03:19]: > > 01 дек. 2014 г., в 22:58, Tony Lindgren написал(а): > > > I think this is a different issue than what I'm seeing. > > Hello, Tony! > > Thank you for testing! > > Could check i2c-omap.c from commit ca1f8da9ac5ce6e63d8f6933f83fabc1f3f961f4. > As all my changes comes after it[1]. So I can understand was the problem > before my work. The issue I'm seeing on 2430sdp is some earlier regression that has started happening over the past year or so. No idea when though as it sometimes works and sometimes does not. So it does not have anything to do with your patches. > I there was no problems, then try with my first commit: > 27caca9d2e01c92b26d0690f065aad093fea01c7 > > The problems you talk about is this? > [9.675994] omap_i2c 48072000.i2c: controller timed out > [ 10.704010] omap_i2c 48072000.i2c: controller timed out > [ 11.734069] omap_i2c 48072000.i2c: controller timed out > root@omap2430sdp:/# [ 12.823638] omap_i2c 48072000.i2c: controller timed out No, I'm seeing just this: omap_i2c 4807.i2c: bus 0 rev3.3 at 100 kHz omap_i2c 48072000.i2c: bus 1 rev3.3 at 100 kHz twl 1-0048: PIH (irq 216) chaining IRQs 217..225 twl 1-0048: power (irq 222) chaining IRQs 225..232 And the system just hangs. With i2c-omap debug enabled, the lines around the twl are: omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) twl 1-0048: PIH (irq 216) chaining IRQs 217..225 twl 1-0048: power (irq 222) chaining IRQs 225..232 omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) And then it hangs. In the working case, the output continues with: omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) twl 1-0048: PIH (irq 216) chaining IRQs 217..225 twl 1-0048: power (irq 222) chaining IRQs 225..232 omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x0049, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x0, stop: 0 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 1, flags: 0x1, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0008) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48072000.i2c: addr: 0x004b, len: 2, flags: 0x0, stop: 1 omap_i2c 48072000.i2c: IRQ (ISR = 0x0010) omap_i2c 48072000.i2c: IRQ (ISR = 0x0004) omap_i2c 48
Re: [PATCH] arm: omap2: rx51-peripherals: fix build warning
Em Thu, 04 Dec 2014 11:03:53 -0600
Felipe Balbi escreveu:
> Hi,
>
> On Thu, Dec 04, 2014 at 03:00:12PM -0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 04 Dec 2014 08:39:31 -0800
> > Tony Lindgren escreveu:
> >
> > > * Felipe Balbi [141204 07:50]:
> > > > Hi,
> > > >
> > > > On Thu, Dec 04, 2014 at 04:41:13PM +0100, Arnd Bergmann wrote:
> > > > > On Thursday 04 December 2014 09:24:11 Felipe Balbi wrote:
> > > > > > On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
> > > > > > > commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> > > > > > > si4713 platform data) updated board-rx51-peripherals.c
> > > > > > > so that si4713 could be easily used on DT boot, but
> > > > > > > it ended up introducing a build warning whenever
> > > > > > > si4713 isn't enabled.
> > > > > > >
> > > > > > > This patches fixes that warning:
> > > > > > >
> > > > > > > arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> > > > > > > ‘rx51_si4713_platform_data’ defined but not used
> > > > > > > [-Wunused-variable]
> > > > > > > static struct si4713_platform_data rx51_si4713_platform_data = {
> > > > > > >
> > > > > > > Cc: Sebastian Reichel
> > > > > > > Cc: Tony Lindgren
> > > > > > > Cc: Hans Verkuil
> > > > > > > Cc: Mauro Carvalho Chehab
> > > > > > > Signed-off-by: Felipe Balbi
> > > > > >
> > > > > > a gentle reminder on this one.
> > > > > >
> > > > >
> > > > > Let me add my
> > > > >
> > > > > Acked-by: Arnd Bergmann
> > > > >
> > > > > You didn't say who you expect to pick up the patch. I assume Mauro
> > > >
> > > > patch author now decides who takes the patch ? That's new :-)
> >
> > Well, for patches that cross subsystem boundaries, like this one,
> > the best is to give a hint about whom you expect to pick it.
> >
> > In this specific case, as commit 68a3c04 is in my tree, the best is
> > to merge the patch on it, as the patch may not even apply at Tony's
> > tree.
>
> pointing to the commit that caused the problem really isn't enough ? The
> commit short description (which is also on my commit log) clearly
> mentions "[media]".
>
> Anyway, I'll do that next time.
Ah, and please c/c linux-media ML next time, as I use patchwork there
to track patches for the media tree.
Thanks,
Mauro.
--
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 0/6] arm: boot: dts: am437x-sk: DTS pinmux fixes
Hi, On Thu, Dec 04, 2014 at 11:04:15AM -0600, Felipe Balbi wrote: > > Here's a small series of non-critical fixes and improvements > > for AM437x Starter Kit DTS. > > > > Basically I'm removing unnecessary pulls and adding explicit > > pinmux for a couple interfaces which were missing. > > > > All patches tested on top of commit 1ca7c60 (Add linux-next > > specific files for 20141204). Boot logs will be attached as > > a reply here. > > boot log attached. no idea why the thing says "-dirty". Just reboot and I get: # uname -a Linux saruman 3.18.0-rc7-next-20141204-9-g8ade679 #2348 SMP Thu Dec 4 11:04:44 CST 2014 armv7l GNU/Linux cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH] arm: omap2: rx51-peripherals: fix build warning
Hi,
On Thu, Dec 04, 2014 at 03:00:12PM -0200, Mauro Carvalho Chehab wrote:
> Em Thu, 04 Dec 2014 08:39:31 -0800
> Tony Lindgren escreveu:
>
> > * Felipe Balbi [141204 07:50]:
> > > Hi,
> > >
> > > On Thu, Dec 04, 2014 at 04:41:13PM +0100, Arnd Bergmann wrote:
> > > > On Thursday 04 December 2014 09:24:11 Felipe Balbi wrote:
> > > > > On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
> > > > > > commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> > > > > > si4713 platform data) updated board-rx51-peripherals.c
> > > > > > so that si4713 could be easily used on DT boot, but
> > > > > > it ended up introducing a build warning whenever
> > > > > > si4713 isn't enabled.
> > > > > >
> > > > > > This patches fixes that warning:
> > > > > >
> > > > > > arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> > > > > > ‘rx51_si4713_platform_data’ defined but not used
> > > > > > [-Wunused-variable]
> > > > > > static struct si4713_platform_data rx51_si4713_platform_data = {
> > > > > >
> > > > > > Cc: Sebastian Reichel
> > > > > > Cc: Tony Lindgren
> > > > > > Cc: Hans Verkuil
> > > > > > Cc: Mauro Carvalho Chehab
> > > > > > Signed-off-by: Felipe Balbi
> > > > >
> > > > > a gentle reminder on this one.
> > > > >
> > > >
> > > > Let me add my
> > > >
> > > > Acked-by: Arnd Bergmann
> > > >
> > > > You didn't say who you expect to pick up the patch. I assume Mauro
> > >
> > > patch author now decides who takes the patch ? That's new :-)
>
> Well, for patches that cross subsystem boundaries, like this one,
> the best is to give a hint about whom you expect to pick it.
>
> In this specific case, as commit 68a3c04 is in my tree, the best is
> to merge the patch on it, as the patch may not even apply at Tony's
> tree.
pointing to the commit that caused the problem really isn't enough ? The
commit short description (which is also on my commit log) clearly
mentions "[media]".
Anyway, I'll do that next time.
> > > > should take it because he took the patch that caused the problem,
> > > > but he might not be aware that he should look at this now.
> > >
> > > He is in Cc, let's ask him :-)
> >
> > Best that this one goes in along with the other si4713 patches
> > to avoid dependencies between trees:
> >
> > Acked-by: Tony Lindgren
>
> Thanks! I'll merge it via my tree.
tks
--
balbi
signature.asc
Description: Digital signature
[PATCH 5/6] arm: boot: dts: am437x-sk: remove internal i2c pullups
AM437x Starter Kit already has discrete pullups
for all I2C buses, so we can (and should) remove
internal pulls.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 5ca9ee7..f8db9b9 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -153,15 +153,15 @@
i2c0_pins: i2c0_pins {
pinctrl-single,pins = <
- 0x188 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* i2c0_sda.i2c0_sda */
- 0x18c (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* i2c0_scl.i2c0_scl */
+ 0x188 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE0) /*
i2c0_sda.i2c0_sda */
+ 0x18c (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE0) /*
i2c0_scl.i2c0_scl */
>;
};
i2c1_pins: i2c1_pins {
pinctrl-single,pins = <
- 0x15c (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE2)
/* spi0_cs0.i2c1_scl */
- 0x158 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE2)
/* spi0_d1.i2c1_sda */
+ 0x15c (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE2) /*
spi0_cs0.i2c1_scl */
+ 0x158 (PIN_INPUT | SLEWCTRL_FAST | MUX_MODE2) /*
spi0_d1.i2c1_sda */
>;
};
--
2.1.0.GIT
--
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 3/6] arm: boot: dts: am437x-sk: remove ethernet pulls
AM437x Starter Kit already has discrete pulls
where they are necessary. It's safe (and actually
better) to remove internal pulls.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 52 ++---
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 5d872f6..68b9529 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -193,32 +193,32 @@
cpsw_default: cpsw_default {
pinctrl-single,pins = <
/* Slave 1 */
- 0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txclk.rmii1_tclk */
- 0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txen.rgmii1_tctl */
- 0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_td0 */
- 0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_td1 */
- 0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_td2 */
- 0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_td3 */
- 0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxclk.rmii1_rclk */
- 0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxdv.rgmii1_rctl */
- 0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rd0 */
- 0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rd1 */
- 0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rd2 */
- 0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rd3 */
+ 0x12c (PIN_OUTPUT | MUX_MODE2) /*
mii1_txclk.rmii1_tclk */
+ 0x114 (PIN_OUTPUT | MUX_MODE2) /*
mii1_txen.rgmii1_tctl */
+ 0x128 (PIN_OUTPUT | MUX_MODE2) /* mii1_txd0.rgmii1_td0
*/
+ 0x124 (PIN_OUTPUT | MUX_MODE2) /* mii1_txd1.rgmii1_td1
*/
+ 0x120 (PIN_OUTPUT | MUX_MODE2) /* mii1_txd0.rgmii1_td2
*/
+ 0x11c (PIN_OUTPUT | MUX_MODE2) /* mii1_txd1.rgmii1_td3
*/
+ 0x130 (PIN_INPUT | MUX_MODE2) /*
mii1_rxclk.rmii1_rclk */
+ 0x118 (PIN_INPUT | MUX_MODE2) /*
mii1_rxdv.rgmii1_rctl */
+ 0x140 (PIN_INPUT | MUX_MODE2) /* mii1_rxd0.rgmii1_rd0
*/
+ 0x13c (PIN_INPUT | MUX_MODE2) /* mii1_rxd1.rgmii1_rd1
*/
+ 0x138 (PIN_INPUT | MUX_MODE2) /* mii1_rxd0.rgmii1_rd2
*/
+ 0x134 (PIN_INPUT | MUX_MODE2) /* mii1_rxd1.rgmii1_rd3
*/
/* Slave 2 */
- 0x58 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a6.rgmii2_tclk */
- 0x40 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a0.rgmii2_tctl */
- 0x54 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a5.rgmii2_td0 */
- 0x50 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a4.rgmii2_td1 */
- 0x4c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a3.rgmii2_td2 */
- 0x48 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a2.rgmii2_td3 */
- 0x5c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a7.rgmii2_rclk */
- 0x44 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a1.rgmii2_rtcl */
- 0x6c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a11.rgmii2_rd0 */
- 0x68 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a10.rgmii2_rd1 */
- 0x64 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a9.rgmii2_rd2 */
- 0x60 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
gpmc_a8.rgmii2_rd3 */
+ 0x58 (PIN_OUTPUT | MUX_MODE2) /* gpmc_a6.rgmii2_tclk
*/
+ 0x40 (PIN_OUTPUT | MUX_MODE2) /* gpmc_a0.rgmii2_tctl
*/
+ 0x54 (PIN_OUTPUT | MUX_MODE2) /* gpmc_a5.rgmii2_td0 */
+ 0x50 (PIN_OUTPUT | MUX_MODE2) /* gpmc_a4.rgmii2_td1 */
+ 0x4c (PIN_OUTPUT | MUX_MODE2) /* gpmc_a3.rgmii2_td2 */
+ 0x48 (PIN_OUTPUT | MUX_MODE2) /* gpmc_a2.rgmii2_td3 */
+ 0x5c (PIN_INPUT | MUX_MODE2)/* gpmc_a7.rgmii2_rclk
*/
+ 0x44 (PIN_INPUT | MUX_MODE2)/* gpmc_a1.rgmii2_rtcl
*/
+ 0x6c (PIN_INPUT | MUX_MODE2)/* gpmc_a11.rgmii2_rd0
*/
+ 0x68 (PIN_INPUT | MUX_MODE2)/* gpmc_a10.rgmii2_rd1
*/
+ 0x64 (PIN_INPUT | MUX_MODE2)/* gpmc_a9.rgmii2_rd2 */
+ 0x60 (PIN_INPUT | MUX_MODE2)/* gpmc_a8.rgmii2_rd3 */
>;
};
@@ -257,8 +257,8 @@
davinci_mdio_default: davinci_mdio_default {
pinctrl-singl
[PATCH 4/6] arm: boot: dts: am437x-sk: add explicit pinmux for both USB instances
This patch just makes USB[01]_DRVVBUS signal
explicitly muxed. Note that board already has
a discrete pulldown, so we're not adding any
pulls here.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 68b9529..5ca9ee7 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -329,6 +329,18 @@
0x1c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpcm_ad7.gpio1_7 */
>;
};
+
+ usb1_pins: usb1_pins {
+ pinctrl-single,pins = <
+ 0x2c0 (PIN_OUTPUT | MUX_MODE0) /*
usb0_drvvbus.usb0_drvvbus */
+ >;
+ };
+
+ usb2_pins: usb2_pins {
+ pinctrl-single,pins = <
+ 0x2c4 (PIN_OUTPUT | MUX_MODE0) /*
usb0_drvvbus.usb0_drvvbus */
+ >;
+ };
};
&i2c0 {
@@ -485,6 +497,8 @@
&usb1 {
dr_mode = "peripheral";
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb1_pins>;
};
&usb2_phy2 {
@@ -494,6 +508,8 @@
&usb2 {
dr_mode = "host";
status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb2_pins>;
};
&qspi {
--
2.1.0.GIT
--
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 6/6] arm: boot: dts: am437x-sk: remove DSS pulls
The DSS data lines don't need pulls, it's best
to remove them to guarantee signal integrity.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 56 ++---
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index f8db9b9..b459bd3 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -272,34 +272,34 @@
dss_pins: dss_pins {
pinctrl-single,pins = <
- 0x020 (PIN_OUTPUT_PULLUP | MUX_MODE1) /* gpmc ad 8 ->
DSS DATA 23 */
- 0x024 (PIN_OUTPUT_PULLUP | MUX_MODE1)
- 0x028 (PIN_OUTPUT_PULLUP | MUX_MODE1)
- 0x02c (PIN_OUTPUT_PULLUP | MUX_MODE1)
- 0x030 (PIN_OUTPUT_PULLUP | MUX_MODE1)
- 0x034 (PIN_OUTPUT_PULLUP | MUX_MODE1)
- 0x038 (PIN_OUTPUT_PULLUP | MUX_MODE1)
- 0x03c (PIN_OUTPUT_PULLUP | MUX_MODE1) /* gpmc ad 15
-> DSS DATA 16 */
- 0x0a0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 0 */
- 0x0a4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0a8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0ac (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0b0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0b4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0b8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0bc (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0c0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0c4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0c8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0cc (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0d0 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0d4 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0d8 (PIN_OUTPUT_PULLUP | MUX_MODE0)
- 0x0dc (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS DATA 15
*/
- 0x0e0 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS VSYNC */
- 0x0e4 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS HSYNC */
- 0x0e8 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS PCLK */
- 0x0ec (PIN_OUTPUT_PULLUP | MUX_MODE0) /* DSS AC BIAS
EN */
+ 0x020 (PIN_OUTPUT | MUX_MODE1) /* gpmc ad 8 -> DSS
DATA 23 */
+ 0x024 (PIN_OUTPUT | MUX_MODE1)
+ 0x028 (PIN_OUTPUT | MUX_MODE1)
+ 0x02c (PIN_OUTPUT | MUX_MODE1)
+ 0x030 (PIN_OUTPUT | MUX_MODE1)
+ 0x034 (PIN_OUTPUT | MUX_MODE1)
+ 0x038 (PIN_OUTPUT | MUX_MODE1)
+ 0x03c (PIN_OUTPUT | MUX_MODE1) /* gpmc ad 15 -> DSS
DATA 16 */
+ 0x0a0 (PIN_OUTPUT | MUX_MODE0) /* DSS DATA 0 */
+ 0x0a4 (PIN_OUTPUT | MUX_MODE0)
+ 0x0a8 (PIN_OUTPUT | MUX_MODE0)
+ 0x0ac (PIN_OUTPUT | MUX_MODE0)
+ 0x0b0 (PIN_OUTPUT | MUX_MODE0)
+ 0x0b4 (PIN_OUTPUT | MUX_MODE0)
+ 0x0b8 (PIN_OUTPUT | MUX_MODE0)
+ 0x0bc (PIN_OUTPUT | MUX_MODE0)
+ 0x0c0 (PIN_OUTPUT | MUX_MODE0)
+ 0x0c4 (PIN_OUTPUT | MUX_MODE0)
+ 0x0c8 (PIN_OUTPUT | MUX_MODE0)
+ 0x0cc (PIN_OUTPUT | MUX_MODE0)
+ 0x0d0 (PIN_OUTPUT | MUX_MODE0)
+ 0x0d4 (PIN_OUTPUT | MUX_MODE0)
+ 0x0d8 (PIN_OUTPUT | MUX_MODE0)
+ 0x0dc (PIN_OUTPUT | MUX_MODE0) /* DSS DATA 15 */
+ 0x0e0 (PIN_OUTPUT | MUX_MODE0) /* DSS VSYNC */
+ 0x0e4 (PIN_OUTPUT | MUX_MODE0) /* DSS HSYNC */
+ 0x0e8 (PIN_OUTPUT | MUX_MODE0) /* DSS PCLK */
+ 0x0ec (PIN_OUTPUT | MUX_MODE0) /* DSS AC BIAS EN */
>;
};
--
2.1.0.GIT
--
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/6] arm: boot: dts: am437x-sk: add explicit MMC0 pinmux
By don't relying on implicit MMC0 pulldown we
make sure that pins are marked busy and even
if we have a broken bootloader, MMC0 will
remain functional.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index d0ce2d4..5d872f6 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -167,6 +167,12 @@
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
+ 0x0f0 (PIN_INPUT | MUX_MODE0) /* mmc0_dat3.mmc0_dat3 */
+ 0x0f4 (PIN_INPUT | MUX_MODE0) /* mmc0_dat2.mmc0_dat2 */
+ 0x0f8 (PIN_INPUT | MUX_MODE0) /* mmc0_dat1.mmc0_dat1 */
+ 0x0fc (PIN_INPUT | MUX_MODE0) /* mmc0_dat0.mmc0_dat0 */
+ 0x100 (PIN_INPUT | MUX_MODE0) /* mmc0_clk.mmc0_clk */
+ 0x104 (PIN_INPUT | MUX_MODE0) /* mmc0_cmd.mmc0_cmd */
0x160 (PIN_INPUT | MUX_MODE7) /* spi0_cs1.gpio0_6 */
>;
};
--
2.1.0.GIT
--
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/6] arm: boot: dts: am437x-sk: remove internal pulls from QSPI
QSPI doesn't need any pullups of any sort,
let's remove them.
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 0eceb8a..d0ce2d4 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -300,12 +300,12 @@
qspi_pins: qspi_pins {
pinctrl-single,pins = <
- 0x7c (PIN_OUTPUT_PULLUP | MUX_MODE3)/*
gpmc_csn0.qspi_csn */
- 0x88 (PIN_OUTPUT | MUX_MODE2) /*
gpmc_csn3.qspi_clk */
- 0x90 (PIN_INPUT_PULLUP | MUX_MODE3) /*
gpmc_advn_ale.qspi_d0 */
- 0x94 (PIN_INPUT_PULLUP | MUX_MODE3) /*
gpmc_oen_ren.qspi_d1 */
- 0x98 (PIN_INPUT_PULLUP | MUX_MODE3) /*
gpmc_wen.qspi_d2 */
- 0x9c (PIN_INPUT_PULLUP | MUX_MODE3) /*
gpmc_be0n_cle.qspi_d3 */
+ 0x7c (PIN_OUTPUT | MUX_MODE3) /* gpmc_csn0.qspi_csn */
+ 0x88 (PIN_OUTPUT | MUX_MODE2) /* gpmc_csn3.qspi_clk */
+ 0x90 (PIN_INPUT | MUX_MODE3)/*
gpmc_advn_ale.qspi_d0 */
+ 0x94 (PIN_INPUT | MUX_MODE3)/* gpmc_oen_ren.qspi_d1
*/
+ 0x98 (PIN_INPUT | MUX_MODE3)/* gpmc_wen.qspi_d2 */
+ 0x9c (PIN_INPUT | MUX_MODE3)/*
gpmc_be0n_cle.qspi_d3 */
>;
};
--
2.1.0.GIT
--
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/6] arm: boot: dts: am437x-sk: DTS pinmux fixes
Here's a small series of non-critical fixes and improvements for AM437x Starter Kit DTS. Basically I'm removing unnecessary pulls and adding explicit pinmux for a couple interfaces which were missing. All patches tested on top of commit 1ca7c60 (Add linux-next specific files for 20141204). Boot logs will be attached as a reply here. Felipe Balbi (6): arm: boot: dts: am437x-sk: remove internal pulls from QSPI arm: boot: dts: am437x-sk: add explicit MMC0 pinmux arm: boot: dts: am437x-sk: remove ethernet pulls arm: boot: dts: am437x-sk: add explicit pinmux for both USB instances arm: boot: dts: am437x-sk: remove internal i2c pullups arm: boot: dts: am437x-sk: remove DSS pulls arch/arm/boot/dts/am437x-sk-evm.dts | 150 +--- 1 file changed, 86 insertions(+), 64 deletions(-) -- 2.1.0.GIT -- 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] arm: omap2: rx51-peripherals: fix build warning
Em Thu, 04 Dec 2014 08:39:31 -0800
Tony Lindgren escreveu:
> * Felipe Balbi [141204 07:50]:
> > Hi,
> >
> > On Thu, Dec 04, 2014 at 04:41:13PM +0100, Arnd Bergmann wrote:
> > > On Thursday 04 December 2014 09:24:11 Felipe Balbi wrote:
> > > > On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
> > > > > commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> > > > > si4713 platform data) updated board-rx51-peripherals.c
> > > > > so that si4713 could be easily used on DT boot, but
> > > > > it ended up introducing a build warning whenever
> > > > > si4713 isn't enabled.
> > > > >
> > > > > This patches fixes that warning:
> > > > >
> > > > > arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> > > > > ‘rx51_si4713_platform_data’ defined but not used
> > > > > [-Wunused-variable]
> > > > > static struct si4713_platform_data rx51_si4713_platform_data = {
> > > > >
> > > > > Cc: Sebastian Reichel
> > > > > Cc: Tony Lindgren
> > > > > Cc: Hans Verkuil
> > > > > Cc: Mauro Carvalho Chehab
> > > > > Signed-off-by: Felipe Balbi
> > > >
> > > > a gentle reminder on this one.
> > > >
> > >
> > > Let me add my
> > >
> > > Acked-by: Arnd Bergmann
> > >
> > > You didn't say who you expect to pick up the patch. I assume Mauro
> >
> > patch author now decides who takes the patch ? That's new :-)
Well, for patches that cross subsystem boundaries, like this one,
the best is to give a hint about whom you expect to pick it.
In this specific case, as commit 68a3c04 is in my tree, the best is
to merge the patch on it, as the patch may not even apply at Tony's
tree.
> >
> > > should take it because he took the patch that caused the problem,
> > > but he might not be aware that he should look at this now.
> >
> > He is in Cc, let's ask him :-)
>
> Best that this one goes in along with the other si4713 patches
> to avoid dependencies between trees:
>
> Acked-by: Tony Lindgren
Thanks! I'll merge it via my tree.
Regards,
Mauro
--
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] hwmon: (gpio-fan) Add a shutdown handler to poweroff the fans
Poweroff the fans when shutting down the system. Else,
echo '1' > /sys/class/hwmon/hwmon0/fan1_target; poweroff leaves the
fan running if the System power off does not drive the gpio expander
which might control the fan power supply.
Signed-off-by: Nishanth Menon
---
based on next-20141204 , but can rebase to required branch as needed.
drivers/hwmon/gpio-fan.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
index 7802eb2..36abf81 100644
--- a/drivers/hwmon/gpio-fan.c
+++ b/drivers/hwmon/gpio-fan.c
@@ -550,6 +550,14 @@ static int gpio_fan_probe(struct platform_device *pdev)
return 0;
}
+static void gpio_fan_shutdown(struct platform_device *pdev)
+{
+ struct gpio_fan_data *fan_data = dev_get_drvdata(&pdev->dev);
+
+ if (fan_data->ctrl)
+ set_fan_speed(fan_data, 0);
+}
+
#ifdef CONFIG_PM_SLEEP
static int gpio_fan_suspend(struct device *dev)
{
@@ -581,6 +589,7 @@ static SIMPLE_DEV_PM_OPS(gpio_fan_pm, gpio_fan_suspend,
gpio_fan_resume);
static struct platform_driver gpio_fan_driver = {
.probe = gpio_fan_probe,
+ .shutdown = gpio_fan_shutdown,
.driver = {
.name = "gpio-fan",
.pm = GPIO_FAN_PM,
--
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] hwmon: (gpio-fan) Allow usage of gpio operations that may sleep
Certain I2C based GPIO expanders could be used in sleepable context,
this results in:
[ 115.890569] [ cut here ]
[ 115.895422] WARNING: CPU: 0 PID: 1115 at drivers/gpio/gpiolib.c:1370
gpiod_set_raw_value+0x40/0x4c()
[ 115.905024] Modules linked in:
[ 115.908229] CPU: 0 PID: 1115 Comm: sh Tainted: GW
3.18.0-rc7-next-20141203-dirty #1
[ 115.917461] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 115.923876] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 115.932013] [] (show_stack) from []
(dump_stack+0x78/0x94)
[ 115.939594] [] (dump_stack) from []
(warn_slowpath_common+0x7c/0xb4)
[ 115.948094] [] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[ 115.957315] [] (warn_slowpath_null) from []
(gpiod_set_raw_value+0x40/0x4c)
[ 115.966457] [] (gpiod_set_raw_value) from []
(set_fan_speed+0x4c/0x64)
[ 115.975145] [] (set_fan_speed) from []
(set_rpm+0x98/0xac)
[ 115.982742] [] (set_rpm) from []
(dev_attr_store+0x18/0x24)
[ 115.990426] [] (dev_attr_store) from []
(sysfs_kf_write+0x4c/0x50)
[ 115.998742] [] (sysfs_kf_write) from []
(kernfs_fop_write+0xbc/0x19c)
[ 116.007333] [] (kernfs_fop_write) from []
(vfs_write+0xb0/0x1a0)
[ 116.015461] [] (vfs_write) from [] (SyS_write+0x44/0x84)
[ 116.022881] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x48)
[ 116.030833] ---[ end trace 3a0b636123acab82 ]---
So, switch over to sleepable GPIO operations as there is no mandatory
need for non-sleepable gpio operations in the fan driver.
This allows the fan driver to be used with i2c based gpio expanders such
as palmas_gpio.
Signed-off-by: Nishanth Menon
---
based on next-20141204 , but can rebase to required branch as needed.
drivers/hwmon/gpio-fan.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c
index 4efa173..7802eb2 100644
--- a/drivers/hwmon/gpio-fan.c
+++ b/drivers/hwmon/gpio-fan.c
@@ -79,7 +79,7 @@ static ssize_t show_fan_alarm(struct device *dev,
{
struct gpio_fan_data *fan_data = dev_get_drvdata(dev);
struct gpio_fan_alarm *alarm = fan_data->alarm;
- int value = gpio_get_value(alarm->gpio);
+ int value = gpio_get_value_cansleep(alarm->gpio);
if (alarm->active_low)
value = !value;
@@ -131,7 +131,7 @@ static void __set_fan_ctrl(struct gpio_fan_data *fan_data,
int ctrl_val)
int i;
for (i = 0; i < fan_data->num_ctrl; i++)
- gpio_set_value(fan_data->ctrl[i], (ctrl_val >> i) & 1);
+ gpio_set_value_cansleep(fan_data->ctrl[i], (ctrl_val >> i) & 1);
}
static int __get_fan_ctrl(struct gpio_fan_data *fan_data)
@@ -142,7 +142,7 @@ static int __get_fan_ctrl(struct gpio_fan_data *fan_data)
for (i = 0; i < fan_data->num_ctrl; i++) {
int value;
- value = gpio_get_value(fan_data->ctrl[i]);
+ value = gpio_get_value_cansleep(fan_data->ctrl[i]);
ctrl_val |= (value << i);
}
return ctrl_val;
@@ -369,7 +369,8 @@ static int fan_ctrl_init(struct gpio_fan_data *fan_data,
if (err)
return err;
- err = gpio_direction_output(ctrl[i], gpio_get_value(ctrl[i]));
+ err = gpio_direction_output(ctrl[i],
+ gpio_get_value_cansleep(ctrl[i]));
if (err)
return err;
}
--
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] arm: omap2: rx51-peripherals: fix build warning
* Felipe Balbi [141204 07:50]:
> Hi,
>
> On Thu, Dec 04, 2014 at 04:41:13PM +0100, Arnd Bergmann wrote:
> > On Thursday 04 December 2014 09:24:11 Felipe Balbi wrote:
> > > On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
> > > > commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> > > > si4713 platform data) updated board-rx51-peripherals.c
> > > > so that si4713 could be easily used on DT boot, but
> > > > it ended up introducing a build warning whenever
> > > > si4713 isn't enabled.
> > > >
> > > > This patches fixes that warning:
> > > >
> > > > arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> > > > ‘rx51_si4713_platform_data’ defined but not used
> > > > [-Wunused-variable]
> > > > static struct si4713_platform_data rx51_si4713_platform_data = {
> > > >
> > > > Cc: Sebastian Reichel
> > > > Cc: Tony Lindgren
> > > > Cc: Hans Verkuil
> > > > Cc: Mauro Carvalho Chehab
> > > > Signed-off-by: Felipe Balbi
> > >
> > > a gentle reminder on this one.
> > >
> >
> > Let me add my
> >
> > Acked-by: Arnd Bergmann
> >
> > You didn't say who you expect to pick up the patch. I assume Mauro
>
> patch author now decides who takes the patch ? That's new :-)
>
> > should take it because he took the patch that caused the problem,
> > but he might not be aware that he should look at this now.
>
> He is in Cc, let's ask him :-)
Best that this one goes in along with the other si4713 patches
to avoid dependencies between trees:
Acked-by: Tony Lindgren
--
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] arm: omap2: rx51-peripherals: fix build warning
Hi,
On Thu, Dec 04, 2014 at 04:41:13PM +0100, Arnd Bergmann wrote:
> On Thursday 04 December 2014 09:24:11 Felipe Balbi wrote:
> > On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
> > > commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> > > si4713 platform data) updated board-rx51-peripherals.c
> > > so that si4713 could be easily used on DT boot, but
> > > it ended up introducing a build warning whenever
> > > si4713 isn't enabled.
> > >
> > > This patches fixes that warning:
> > >
> > > arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> > > ‘rx51_si4713_platform_data’ defined but not used [-Wunused-variable]
> > > static struct si4713_platform_data rx51_si4713_platform_data = {
> > >
> > > Cc: Sebastian Reichel
> > > Cc: Tony Lindgren
> > > Cc: Hans Verkuil
> > > Cc: Mauro Carvalho Chehab
> > > Signed-off-by: Felipe Balbi
> >
> > a gentle reminder on this one.
> >
>
> Let me add my
>
> Acked-by: Arnd Bergmann
>
> You didn't say who you expect to pick up the patch. I assume Mauro
patch author now decides who takes the patch ? That's new :-)
> should take it because he took the patch that caused the problem,
> but he might not be aware that he should look at this now.
He is in Cc, let's ask him :-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] arm: omap2: rx51-peripherals: fix build warning
On Thursday 04 December 2014 09:24:11 Felipe Balbi wrote:
> On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
> > commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> > si4713 platform data) updated board-rx51-peripherals.c
> > so that si4713 could be easily used on DT boot, but
> > it ended up introducing a build warning whenever
> > si4713 isn't enabled.
> >
> > This patches fixes that warning:
> >
> > arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> > ‘rx51_si4713_platform_data’ defined but not used [-Wunused-variable]
> > static struct si4713_platform_data rx51_si4713_platform_data = {
> >
> > Cc: Sebastian Reichel
> > Cc: Tony Lindgren
> > Cc: Hans Verkuil
> > Cc: Mauro Carvalho Chehab
> > Signed-off-by: Felipe Balbi
>
> a gentle reminder on this one.
>
Let me add my
Acked-by: Arnd Bergmann
You didn't say who you expect to pick up the patch. I assume Mauro
should take it because he took the patch that caused the problem,
but he might not be aware that he should look at this now.
Arnd
--
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] arm: omap2: rx51-peripherals: fix build warning
On Wed, Nov 26, 2014 at 02:27:35PM -0600, Felipe Balbi wrote:
> commit 68a3c04 ([media] ARM: OMAP2: RX-51: update
> si4713 platform data) updated board-rx51-peripherals.c
> so that si4713 could be easily used on DT boot, but
> it ended up introducing a build warning whenever
> si4713 isn't enabled.
>
> This patches fixes that warning:
>
> arch/arm/mach-omap2/board-rx51-peripherals.c:1000:36: warning: \
> ‘rx51_si4713_platform_data’ defined but not used [-Wunused-variable]
> static struct si4713_platform_data rx51_si4713_platform_data = {
>
> Cc: Sebastian Reichel
> Cc: Tony Lindgren
> Cc: Hans Verkuil
> Cc: Mauro Carvalho Chehab
> Signed-off-by: Felipe Balbi
a gentle reminder on this one.
> ---
> arch/arm/mach-omap2/board-rx51-peripherals.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c
> index d18a5cf..bda20c5 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -997,9 +997,11 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
> .gpio_reset = 60,
> };
>
> +#if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
> static struct si4713_platform_data rx51_si4713_platform_data = {
> .is_platform_device = true
> };
> +#endif
>
> static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[]
> = {
> #if IS_ENABLED(CONFIG_I2C_SI4713) && IS_ENABLED(CONFIG_PLATFORM_SI4713)
> --
> 2.1.0.GIT
>
--
balbi
signature.asc
Description: Digital signature
[PATCH] ARM: dts: am437x-sk-evm: Hook dcdc2 as the cpu0-supply
From: Dave Gerlach
Hook dcdc2 as the cpu0-supply.
Signed-off-by: Dave Gerlach
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index 87aa4f3..f7f77a7 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -611,3 +611,7 @@
&wdt {
status = "okay";
};
+
+&cpu {
+ cpu0-supply = <&dcdc2>;
+};
--
2.1.0.GIT
--
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] arm: boot: dts: am437x-sk: fix lcd enable pin mux data
Caused by a copy & paste error. Note that even with
this bug AM437x SK display still works because GPIO
mux mode is always enabled. It's still wrong to mux
somebody else's pin.
Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
isn't used for anything.
While at that, also replace a pullup with a pulldown
as that gpio should be normally low, not high.
Cc: # v3.17+
Acked-by: Tomi Valkeinen
Signed-off-by: Felipe Balbi
---
arch/arm/boot/dts/am437x-sk-evm.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
b/arch/arm/boot/dts/am437x-sk-evm.dts
index f7f77a7..0eceb8a 100644
--- a/arch/arm/boot/dts/am437x-sk-evm.dts
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -320,8 +320,7 @@
lcd_pins: lcd_pins {
pinctrl-single,pins = <
- /* GPIO 5_8 to select LCD / HDMI */
- 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
+ 0x1c (PIN_OUTPUT_PULLDOWN | MUX_MODE7) /*
gpcm_ad7.gpio1_7 */
>;
};
};
--
2.1.0.GIT
--
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 3/3] arm: boot: dts: am437x-sk: fix lcd enable pin mux data
On Thu, Dec 04, 2014 at 08:43:25AM -0600, Felipe Balbi wrote:
> HI,
>
> On Wed, Oct 15, 2014 at 03:24:20PM +0300, Tomi Valkeinen wrote:
> > On 14/10/14 21:28, Felipe Balbi wrote:
> > > Caused by a copy & paste error. Note that even with
> > > this bug AM437x SK display still works because GPIO
> > > mux mode is always enabled. It's still wrong to mux
> > > somebody else's pin.
> > >
> > > Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
> > > isn't used for anything.
> > >
> > > Signed-off-by: Felipe Balbi
> > > ---
> > > arch/arm/boot/dts/am437x-sk-evm.dts | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
> > > b/arch/arm/boot/dts/am437x-sk-evm.dts
> > > index 859ff3d..681be00 100644
> > > --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> > > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > > @@ -320,8 +320,7 @@
> > >
> > > lcd_pins: lcd_pins {
> > > pinctrl-single,pins = <
> > > - /* GPIO 5_8 to select LCD / HDMI */
> > > - 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
> > > + 0x1c (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
> > > gpcm_ad7.gpio1_7 */
> > > >;
> > > };
> > > };
> >
> > I didn't verify the offset, but based on the comments this looks fine to me.
> >
> > Acked-by: Tomi Valkeinen
>
> Tony, are you taking this patch ? Looks like it has been forgotten and
> now it needs to be backported to v3.17 and v3.18 (assuming it's too late
> for v3.18).
I'll send a new version and Cc stable.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v2] drivers: net : cpsw: Update Kconfig for CPSW
On Thu, Dec 04, 2014 at 10:24:29AM +0530, Lokesh Vutla wrote: > CPSW is present in AM33xx, AM43xx, DRA7xx. > Updating the Kconfig to depend on ARCH_OMAP2PLUS instead of listing > all SoC's. > > Signed-off-by: Lokesh Vutla Reviewed-by: Felipe Balbi > --- > drivers/net/ethernet/ti/Kconfig | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig > index 5d8cb79..7051255 100644 > --- a/drivers/net/ethernet/ti/Kconfig > +++ b/drivers/net/ethernet/ti/Kconfig > @@ -5,7 +5,7 @@ > config NET_VENDOR_TI > bool "Texas Instruments (TI) devices" > default y > - depends on PCI || EISA || AR7 || (ARM && (ARCH_DAVINCI || ARCH_OMAP3 || > SOC_AM33XX || ARCH_KEYSTONE)) > + depends on PCI || EISA || AR7 || ARCH_DAVINCI || ARCH_OMAP2PLUS || > ARCH_KEYSTONE > ---help--- > If you have a network (Ethernet) card belonging to this class, say Y > and read the Ethernet-HOWTO, available from > @@ -32,7 +32,7 @@ config TI_DAVINCI_EMAC > > config TI_DAVINCI_MDIO > tristate "TI DaVinci MDIO Support" > - depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 || SOC_AM33XX || > ARCH_KEYSTONE ) > + depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE > select PHYLIB > ---help--- > This driver supports TI's DaVinci MDIO module. > @@ -42,7 +42,7 @@ config TI_DAVINCI_MDIO > > config TI_DAVINCI_CPDMA > tristate "TI DaVinci CPDMA Support" > - depends on ARM && ( ARCH_DAVINCI || ARCH_OMAP3 || SOC_AM33XX ) > + depends on ARCH_DAVINCI || ARCH_OMAP2PLUS > ---help--- > This driver supports TI's DaVinci CPDMA dma engine. > > @@ -58,7 +58,7 @@ config TI_CPSW_PHY_SEL > > config TI_CPSW > tristate "TI CPSW Switch Support" > - depends on ARM && (ARCH_DAVINCI || SOC_AM33XX) > + depends on ARCH_DAVINCI || ARCH_OMAP2PLUS > select TI_DAVINCI_CPDMA > select TI_DAVINCI_MDIO > select TI_CPSW_PHY_SEL > -- > 1.9.1 > -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/3] arm: boot: dts: am437x-sk: fix lcd enable pin mux data
HI,
On Wed, Oct 15, 2014 at 03:24:20PM +0300, Tomi Valkeinen wrote:
> On 14/10/14 21:28, Felipe Balbi wrote:
> > Caused by a copy & paste error. Note that even with
> > this bug AM437x SK display still works because GPIO
> > mux mode is always enabled. It's still wrong to mux
> > somebody else's pin.
> >
> > Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x
> > isn't used for anything.
> >
> > Signed-off-by: Felipe Balbi
> > ---
> > arch/arm/boot/dts/am437x-sk-evm.dts | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am437x-sk-evm.dts
> > b/arch/arm/boot/dts/am437x-sk-evm.dts
> > index 859ff3d..681be00 100644
> > --- a/arch/arm/boot/dts/am437x-sk-evm.dts
> > +++ b/arch/arm/boot/dts/am437x-sk-evm.dts
> > @@ -320,8 +320,7 @@
> >
> > lcd_pins: lcd_pins {
> > pinctrl-single,pins = <
> > - /* GPIO 5_8 to select LCD / HDMI */
> > - 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
> > + 0x1c (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
> > gpcm_ad7.gpio1_7 */
> > >;
> > };
> > };
>
> I didn't verify the offset, but based on the comments this looks fine to me.
>
> Acked-by: Tomi Valkeinen
Tony, are you taking this patch ? Looks like it has been forgotten and
now it needs to be backported to v3.17 and v3.18 (assuming it's too late
for v3.18).
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] hsi / OMAP / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
On Wednesday 03 December 2014 23:45:22 Rafael J. Wysocki wrote: > http://marc.info/?l=linux-kernel&m=141712284917133&w=4 > > > Before we do lots of s/CONFIG_PM_SLEEP/CONFIG_PM/ changes in lots of > > other drivers, it would be nice to come up with a new set of macros > > to replace all the SET_RUNTIME_PM_OPS/SIMPLE_DEV_PM_OPS/..._OPS > > with a version that avoided the #ifdefs altogether. > > I don't think we can avoid all of the #ifdefs and the macros still work > (except for one which is redundant, but I have a patch to clean that up). Right, while we can create a version that does not require the #ifdef, that would still mean we'd have to touch every file and replace SET_RUNTIME_PM_OPS with PM_SET_RUNTIME_OPS or something like that because the new macro would not work if the function is not defined. Arnd -- 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
