Re: [PATCH] ARM: OMAP5: DSS hwmod data
Hi Paul, On Thursday 08 May 2014 09:31 PM, Paul Walmsley wrote: snip The problem is that we have multiple hwmods which use the same MODULEMODE bit. There is no use-counting done when it comes to enabling/disabling modulemode. If there was such a thing, we could have provided MODULEMODE flags even for the children hwmods. Thanks for the summary. This is indeed a long-overdue item for the hwmod core code. Can you please patch the hwmod core code to add this? I'd suggest making the use-counting functionality conditional on a hwmod flag that you can set for all of the DSS hwmods. (Ideally, the core code would detect that several modules share the same MODULEMODE bits, and automatically set it for those cases, but that seems a bit too complex for a first cut.) Sure, I can work on this. Archit -- 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: am33xx: Move the cppi41dma node so it's probed early
On 5/8/2014 10:30 PM, Ezequiel García wrote:
Hi George,
On 29 April 2014 04:58, George Cherian george.cher...@ti.com wrote:
On 4/29/2014 11:49 AM, Yegor Yefremov wrote:
On Thu, Apr 24, 2014 at 11:11 PM, Ezequiel Garcia
ezequ...@vanguardiasur.com.ar wrote:
The DMA controller is needed for the USB controller to be correctly
registered. Therefore, if the DMA node is located at the end an
unecessary
probe deferral is produced systematically.
This is easily fixed by moving the node at the beggining of the child
list,
so it's probed first.
This will give issues on module removal.
Since we use device_for_each_child in remove patch, it will try to remove
cppi dma controller, while the channel
is still in use by musb node.
OK, this seems confusing: are you sure module removal works?
No it does not .
Doing this simple test on v3.15-rcN:
$ modprobe musb_dsps
$ modprobe musb_am335x
$ modprobe musb_am335x -r
And the kernel blows up :-(
I've been debugging this and I think we simply cannot support removal
of the musb_am335x
module.
Had this ever worked before
Nope. I feel the whole problem is because how its modeled in dt.
If you look at the TRM following are the memory maps for the USB modules
USB control Module 0x44e10_0620
USBSS 0x4740_
USB0 0x4740_1000
USB0_PHY 0x4740_1300
USB0_CORE0x4740_1400
USB1 0x4740_1800
USB1_PHY 0x4740_1b00
USB1_CORE0x4740_1c00
CPPI DMA Controller 0x4740_2000
CPPI DMA Scheduler 0x4740_3000
Queue Manager 0x4740_4000
Now in the curent DT we have the follwoing
USBSS {
usb_ctrl_mod: {
0x44e10_0620
}
usb0_phy:{
0x4740_1300
}
usb0: {
0x4740_1000
0x4740_1400
}
usb1_phy: {
0x4740_1b00
}
usb1:{
0x4740_1800
0x4740_1c00
}
cppi41dma: {
0x4740_2000
0x4740_3000
0x4740_4000
}
}
Just by remodelling the dt the whole problem can be solved.
I am still not convinced why we should not be doing it?
Because neither ways its not the exact representation of the H/W.
I will send a patch as RFC for the same.
--
-George
--
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
[RFC PATCH] ARM: dts: am33xx: Re-arrange the USB dt to reflect the h/w configuration
Re arrange the USB dt for AM33xx to take it a bit closer
to the hardware configuration.
The USBSS is designed as follows
USB control Module 0x44e10_0620
USBSS 0x4740_
USB00x4740_1000
USB0_PHY0x4740_1300
USB0_CORE 0x4740_1400
USB10x4740_1800
USB1_PHY0x4740_1b00
USB1_CORE 0x4740_1c00
CPPI DMA Controller 0x4740_2000
CPPI DMA Scheduler 0x4740_3000
Queue Manager 0x4740_4000
So model the DT as follows
USBSS {
usb_ctrl_mod: {
0x44e10_0620
}
usb0: {
0x4740_1000
0x4740_1400
}
usb0_phy:{
0x4740_1300
}
usb1:{
0x4740_1800
0x4740_1c00
}
usb1_phy: {
0x4740_1b00
}
cppi41dma: {
0x4740_2000
0x4740_3000
0x4740_4000
}
}
Signed-off-by: George Cherian george.cher...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index cb6811e..d33a1e7 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -461,14 +461,6 @@
status = disabled;
};
- usb0_phy: usb-phy@47401300 {
- compatible = ti,am335x-usb-phy;
- reg = 0x47401300 0x100;
- reg-names = phy;
- status = disabled;
- ti,ctrl_mod = usb_ctrl_mod;
- };
-
usb0: usb@47401000 {
compatible = ti,musb-am33xx;
status = disabled;
@@ -509,9 +501,9 @@
tx14, tx15;
};
- usb1_phy: usb-phy@47401b00 {
+ usb0_phy: usb-phy@47401300 {
compatible = ti,am335x-usb-phy;
- reg = 0x47401b00 0x100;
+ reg = 0x47401300 0x100;
reg-names = phy;
status = disabled;
ti,ctrl_mod = usb_ctrl_mod;
@@ -556,6 +548,14 @@
tx14, tx15;
};
+ usb1_phy: usb-phy@47401b00 {
+ compatible = ti,am335x-usb-phy;
+ reg = 0x47401b00 0x100;
+ reg-names = phy;
+ status = disabled;
+ ti,ctrl_mod = usb_ctrl_mod;
+ };
+
cppi41dma: dma-controller@47402000 {
compatible = ti,am3359-cppi41;
reg = 0x4740 0x1000
--
1.8.3.1
--
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: OMAP5: DSS hwmod data
On 08/05/14 19:01, Paul Walmsley wrote: Hi Archit, On Thu, 8 May 2014, Archit Taneja wrote: Hi Paul, On Thursday 08 May 2014 10:07 AM, Paul Walmsley wrote: Hi, On Wed, 12 Mar 2014, Tomi Valkeinen wrote: This patch adds hwmod data for omap5 display subsystem. I have tested this on omap5-uevm with a DSI panel. I cannot test omap5-uevm's hdmi output yet, as the mainline is missing omap5 HDMI driver. I do see this when booting: omap_hwmod: dss_dispc: cannot be enabled for reset (3) omap_hwmod: dss_dsi1: cannot be enabled for reset (3) omap_hwmod: dss_dsi2: cannot be enabled for reset (3) omap_hwmod: dss_hdmi: cannot be enabled for reset (3) omap_hwmod: dss_rfbi: cannot be enabled for reset (3) But at least DSI works just fine. Am looking at this for v3.16. But I think someone needs to take a look at those warnings and figure out why they are happening. We associate DSS clock domain's MODULEMODE bits only with the dss_core hwmod. The rest of the dss hwmods don't touch MODULEMODE. Therefore, these hwmods cannot be enabled independently, and reset. We don't face this issue in the omapdss driver since the platform devices corresponding to these hwmods have their parent as the platform device corresponding to 'dss_core'. This parent child-relation ensures that 'dss_core' is enabled when the a child calls a pm_runtime_get function. The problem is that we have multiple hwmods which use the same MODULEMODE bit. There is no use-counting done when it comes to enabling/disabling modulemode. If there was such a thing, we could have provided MODULEMODE flags even for the children hwmods. Thanks for the summary. This is indeed a long-overdue item for the hwmod core code. Can you please patch the hwmod core code to add this? I'd suggest making the use-counting functionality conditional on a hwmod flag that you can set for all of the DSS hwmods. (Ideally, the core code would detect that several modules share the same MODULEMODE bits, and automatically set it for those cases, but that seems a bit too complex for a first cut.) Can we still go forward with this patch as it is? As far as I understand, the warnings are harmless (more or less), but without this patch we won't have OMAP5 display support. Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP baseline test results for v3.15-rc4
On 8 May 2014 17:00, Paul Walmsley p...@pwsan.com wrote: Hello Joachim, On Thu, 8 May 2014, Joachim Eastwood wrote: On 8 May 2014 06:23, Paul Walmsley p...@pwsan.com wrote: Here are some basic OMAP test results for Linux v3.15-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.15-rc4/20140505112251/ Test summary snip The eMMC on the 4460 VAR-SOM-OM has failed; I guess it's run out of reserve blocks to reallocate. Now it's time to find yet another way to boot it. I have some patches for u-boot which makes it possible to use the on-board LAN7500 USB Ethernet controller for tftp. That's great! I haven't had time to upstream it yet, but I'll send you a WIP version. These patches are also needed for USB in Linux since the on-board USB hub requires some special setup that I have put in u-boot. Since you have a VAR-SOM-OM44 module maybe you could test my dts patches for it? I will post a new version of the patch set early next week. I can cc you. I'd like to load the rootfs off the external SD slot. Looks like you might be adding support for that with your recent DT patches? Yes, the external SD slot (sdmmc5) is supported in the dts. It worked last time I tested it, but I haven't tried to use it for rootfs. Do you have the VAR-DVK-OM44 eval board? Yes. Nice :-) Then you see if the display stuff is working with DT also. regards Joachim Eastwood -- 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 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
On 09/05/14 02:36, Tony Lindgren wrote:
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
This looks very board specific to me... The regulator and the use of
mcspi1 depend on the board, so this file can't be used on just any omap
board with the same panel. And this can (probably) only be used on
boards with a single display. Do those boards have tv-out?
So I have nothing against having common files, but shouldn't this be
named something more specific? If the boards involved are TI's OMAP3
development boards, maybe this should be something like...
omap3-ti-dev-panel-sharp-ls037v7dw01.dtsi. Well, that's a quite long one.
+/ {
+ aliases {
+ display0 = lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = gpio-backlight;
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = regulator-fixed;
+ regulator-name = lcd_3v3;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ startup-delay-us = 7;
+ regulator-always-on;
Why always-on?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
On 09/05/14 02:33, Tony Lindgren wrote:
We can pass the GPIO configuration for ls037v7dw01 in a standard
gpios property.
Signed-off-by: Tony Lindgren t...@atomide.com
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls037v7dw01.txt
@@ -0,0 +1,56 @@
+SHARP LS037V7DW01 TFT-LCD panel
+
+Required properties:
+- compatible: should be sharp,ls037v7dw01
+
+Optional properties:
+- enable-gpios: a GPIO spec for the optional enable pin
+ this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+ this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
The video port data is required also. See for example
Documentation/devicetree/bindings/video/panel-dsi-cm.txt or
Documentation/devicetree/bindings/video/hdmi-connector.txt.
Also, all the bindings I've made are in
Documentation/devicetree/bindings/video/, and I'd rather keep the video
bindings OMAP uses in the same place.
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example when connected to a omap2+ based device:
+
+ lcd0: display {
+ compatible = sharp,ls037v7dw01;
+ power-supply = lcd_3v3;
+ enable-gpios = gpio5 24 GPIO_ACTIVE_HIGH;/* gpio152, lcd
INI */
+ reset-gpios = gpio5 27 GPIO_ACTIVE_HIGH; /* gpio155, lcd
RESB */
+ mode-gpios = gpio5 26 GPIO_ACTIVE_HIGH/* gpio154, lcd
MO */
+ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd
LR */
+ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd
UD */
+
+ panel-timing {
+ clock-frequency = 1920;
+ hback-porch = 28;
+ hactive = 480;
+ hfront-porch = 1;
+ hsync-len = 2;
+ vback-porch = 1;
+ vactive = 640;
+ vfront-porch = 1;
+ vsync-len = 1;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
I don't think we should define panel-timing here. We know it's
sharp,ls037v7dw01, so the driver knows the video timings. Also, if we
would extend the driver to support both resolution modes, it needs to
support two different timings, so the above doesn't work in that case
either.
Although if the MO gpio is not controlled by the driver, we should tell
the driver whether that gpio is high or low.
+static int sharp_ls_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ struct display_timing timing;
+ struct videomode vm;
+ int r;
+
+ ddata-vcc = devm_regulator_get(pdev-dev, envdd);
+ if (IS_ERR(ddata-vcc)) {
+ dev_err(pdev-dev, failed to get regulator\n);
+ return PTR_ERR(ddata-vcc);
+ }
+
+ r = regulator_enable(ddata-vcc);
+ if (r != 0) {
+ dev_err(pdev-dev, failed to enable regulator\n);
+ return r;
+ }
The regulator should be enabled when the panel is enabled, not at probe
time.
+static const struct of_device_id sharp_ls_of_match[] = {
+ { .compatible = sharp,ls037v7dw01, },
At the moment our display drivers are OMAP specific, and for that reason
we should prefix the compatible strings with omapdss,. For example,
drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
{ .compatible = omapdss,panel-dsi-cm, },
But we should still have the right compatible string in the .dts, so we
convert the compatible name in arch/arm/mach-omap2/display.c, with
'dss_compat_conv_list' array, to which this panel's name should be added.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On 05/09/2014 08:22 AM, George Cherian wrote: Just by remodelling the dt the whole problem can be solved. I am still not convinced why we should not be doing it? Because neither ways its not the exact representation of the H/W. Ha. Now I am confused. First I assumed that the musb_am335x module is built-in only to duct-tape the bug you are seeing. So this patch never made it mainline then. The problem is as far as I remember the way the phy-core does things and should be fixed. Re-arranging does not help because you can still oops the kernel (the same oops you have now) by removing the devices manually via sysfs. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On 30/04/14 02:52, Tony Lindgren wrote:
Otherwise we can get often errors like the following and the
display won't come on:
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
omapdss APPLY error: SYNC_LOST on channel lcd, restarting
the output with video overlays disabled
There are some earlier references to this issue:
http://www.spinics.net/lists/linux-omap/msg59511.html
http://www.spinics.net/lists/linux-omap/msg59724.html
Those don't sound like the same issue, but it's hard to say. What kind
of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
without this patch?
What resolution do you have? If it's a very high resolution (say, DVI
output to a monitor), it could just be an issue of
not-enough-memory-bandwidth.
It seems that it's safe to set the lower values even for 3630.
If we can confirm that 3630 works with the higher values
reliably we can add further detection.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..ad6561f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats
__initconst = {
.dpi_select_source = dss_dpi_select_source_omap2_omap3,
};
+/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
static const struct dss_features omap3630_dss_feats __initconst = {
- .fck_div_max= 32,
- .dss_fck_multiplier = 1,
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
These values tell about the clock hardware, they are not settings that
can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
and a divider with maximum value of 16.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] gpio: always enable GPIO_OMAP on ARCH_OMAP
On Mon, Apr 28, 2014 at 11:07 AM, Arnd Bergmann a...@arndb.de wrote: Commit 4df42de9d3e gpio: omap: add a GPIO_OMAP option instead of using ARCH_OMAP made it possible to build OMAP kernels without the GPIO driver, which at least on OMAP2 and OMAP3 causes build errors because of functions used by the platform power management code: arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle': arch/arm/mach-omap2/pm24xx.c:129: undefined reference to `omap2_gpio_prepare_for_idle' arch/arm/mach-omap2/pm24xx.c:129: undefined reference to `omap2_gpio_resume_after_idle' We presumably always want the GPIO driver on OMAP, so this adds a slightly broader dependency and only allows disabling the driver only when no OMAP2PLUS platform is selected. However, it seems entirely reasonable to include the driver in build tests on other platforms, so we should also allow building it for COMPILE_TEST builds and select the required GENERIC_IRQ_CHIP that may not already be enabled on other platforms. Signed-off-by: Arnd Bergmann a...@arndb.de Patch applied to my devel branch, this is not a fix to Torvalds HEAD AFAICT, but a fix to v3.16? Else poke me. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: omap5: hwmod_data: Add AESS related data
Paul,
On 04/30/2014 02:43 PM, Peter Ujfalusi wrote:
Add the needed hwmod entries which is needed for AESS (Audio Engine
SubSystem) and ABE.
please ignore this patch to add AESS to hwmod data. W/o addresses defined we
will see warnings printed. So either I add the addresses to hwmod data or need
to have aess also in DT.
--
Péter
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 64
++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index e829664e6a6c..3e20c025b5a4 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -146,6 +146,7 @@ static struct omap_hwmod omap54xx_l4_abe_hwmod = {
.prcm = {
.omap4 = {
.clkctrl_offs = OMAP54XX_CM_ABE_L4_ABE_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_ABE_AESS_CONTEXT_OFFSET,
.flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
},
},
@@ -211,6 +212,42 @@ static struct omap_hwmod omap54xx_mpu_private_hwmod = {
};
/*
+ * 'aess' class
+ * audio engine sub system
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_aess_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART |
+MSTANDBY_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap54xx_aess_hwmod_class = {
+ .name = aess,
+ .sysc = omap54xx_aess_sysc,
+ .enable_preprogram = omap_hwmod_aess_preprogram,
+};
+
+/* aess */
+static struct omap_hwmod omap54xx_aess_hwmod = {
+ .name = aess,
+ .class = omap54xx_aess_hwmod_class,
+ .clkdm_name = abe_clkdm,
+ .main_clk = aess_fclk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_ABE_AESS_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_ABE_AESS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'counter' class
* 32-bit ordinary counter, clocked by the falling edge of the 32 khz clock
*/
@@ -1892,6 +1929,14 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__l3_main_3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* aess - l4_abe */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_aess__l4_abe = {
+ .master = omap54xx_aess_hwmod,
+ .slave = omap54xx_l4_abe_hwmod,
+ .clk= abe_iclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l3_main_1 - l4_abe */
static struct omap_hwmod_ocp_if omap54xx_l3_main_1__l4_abe = {
.master = omap54xx_l3_main_1_hwmod,
@@ -1966,6 +2011,22 @@ static struct omap_hwmod_ocp_if
omap54xx_l4_cfg__dma_system = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_abe - aess */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_l4_abe__aess = {
+ .master = omap54xx_l4_abe_hwmod,
+ .slave = omap54xx_aess_hwmod,
+ .clk= abe_iclk,
+ .user = OCP_USER_MPU,
+};
+
+/* l4_abe - aess (dma) */
+static struct omap_hwmod_ocp_if __maybe_unused omap54xx_l4_abe__aess_dma = {
+ .master = omap54xx_l4_abe_hwmod,
+ .slave = omap54xx_aess_hwmod,
+ .clk= abe_iclk,
+ .user = OCP_USER_SDMA,
+};
+
/* l4_abe - dmic */
static struct omap_hwmod_ocp_if omap54xx_l4_abe__dmic = {
.master = omap54xx_l4_abe_hwmod,
@@ -2417,6 +2478,9 @@ static struct omap_hwmod_ocp_if
*omap54xx_hwmod_ocp_ifs[] __initdata = {
omap54xx_l3_main_1__l3_main_3,
omap54xx_l3_main_2__l3_main_3,
omap54xx_l4_cfg__l3_main_3,
+ omap54xx_l4_abe__aess,
+ omap54xx_l4_abe__aess_dma,
+ omap54xx_aess__l4_abe,
omap54xx_l3_main_1__l4_abe,
omap54xx_mpu__l4_abe,
omap54xx_l3_main_1__l4_cfg,
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
On 09/05/14 02:20, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140429 16:53]: Otherwise we can get often errors like the following and the display won't come on: omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay omapdss APPLY error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled There are some earlier references to this issue: http://www.spinics.net/lists/linux-omap/msg59511.html http://www.spinics.net/lists/linux-omap/msg59724.html It seems that it's safe to set the lower values even for 3630. If we can confirm that 3630 works with the higher values reliably we can add further detection. BTW, I'm also seeing this warning on 3730-evm it may be related: [3.523101] [ cut here ] [3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c() [3.538360] clk rate mismatch: 10800 != 11520 [3.543518] Modules linked in: Hmm... Can you paste the clk_summary from debugfs? Somehow the clock framework calculates the clock rate differently than the dss. Or do we have different clock.dts files used for 3730 and 3630? Tomi signature.asc Description: OpenPGP digital signature
[PATCH v2] ARM: omap5: hwmod_data: Correct IDLEMODE for McPDM
McPDM need to be configured to NO_IDLE mode when it is in used otherwise
vital clocks will be gated which results 'slow motion' audio playback.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Paul,
Changes since v1:
- updated the commit message
If this can still make it to 3.15, that would be great.
Regards,
Peter
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 892317294fdc..e829664e6a6c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -895,7 +895,7 @@ static struct omap_hwmod omap54xx_mcpdm_hwmod = {
* current exception.
*/
- .flags = HWMOD_EXT_OPT_MAIN_CLK,
+ .flags = HWMOD_EXT_OPT_MAIN_CLK | HWMOD_SWSUP_SIDLE,
.main_clk = pad_clks_ck,
.prcm = {
.omap4 = {
--
1.9.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap4: hwmod_data: Clean up audio related structures (remove/merge them)
All audio related omap_hwmod_ocp_if *_dma can be removed from the data since
we can just add the user flag to the non dma structure.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 +++---
1 file changed, 9 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 1219280bb976..41e54f759934 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -3635,15 +3635,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__dmic = {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_dmic_hwmod,
.clk= ocp_abe_iclk,
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe - dmic (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__dmic_dma = {
- .master = omap44xx_l4_abe_hwmod,
- .slave = omap44xx_dmic_hwmod,
- .clk= ocp_abe_iclk,
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* dsp - iva */
@@ -4209,15 +4201,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1
= {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_mcbsp1_hwmod,
.clk= ocp_abe_iclk,
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe - mcbsp1 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp1_dma = {
- .master = omap44xx_l4_abe_hwmod,
- .slave = omap44xx_mcbsp1_hwmod,
- .clk= ocp_abe_iclk,
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_abe - mcbsp2 */
@@ -4225,15 +4209,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp2
= {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_mcbsp2_hwmod,
.clk= ocp_abe_iclk,
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe - mcbsp2 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp2_dma = {
- .master = omap44xx_l4_abe_hwmod,
- .slave = omap44xx_mcbsp2_hwmod,
- .clk= ocp_abe_iclk,
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_abe - mcbsp3 */
@@ -4241,15 +4217,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp3
= {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_mcbsp3_hwmod,
.clk= ocp_abe_iclk,
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe - mcbsp3 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcbsp3_dma = {
- .master = omap44xx_l4_abe_hwmod,
- .slave = omap44xx_mcbsp3_hwmod,
- .clk= ocp_abe_iclk,
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_per - mcbsp4 */
@@ -4265,15 +4233,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcpdm =
{
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_mcpdm_hwmod,
.clk= ocp_abe_iclk,
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe - mcpdm (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__mcpdm_dma = {
- .master = omap44xx_l4_abe_hwmod,
- .slave = omap44xx_mcpdm_hwmod,
- .clk= ocp_abe_iclk,
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_per - mcspi1 */
@@ -4575,15 +4535,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__timer5
= {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_timer5_hwmod,
.clk= ocp_abe_iclk,
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe - timer5 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__timer5_dma = {
- .master = omap44xx_l4_abe_hwmod,
- .slave = omap44xx_timer5_hwmod,
- .clk= ocp_abe_iclk,
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_abe - timer6 */
@@ -4591,15 +4543,7 @@ static struct omap_hwmod_ocp_if omap44xx_l4_abe__timer6
= {
.master = omap44xx_l4_abe_hwmod,
.slave = omap44xx_timer6_hwmod,
.clk= ocp_abe_iclk,
- .user = OCP_USER_MPU,
-};
-
-/* l4_abe - timer6 (dma) */
-static struct omap_hwmod_ocp_if omap44xx_l4_abe__timer6_dma = {
- .master = omap44xx_l4_abe_hwmod,
- .slave = omap44xx_timer6_hwmod,
- .clk= ocp_abe_iclk,
- .user = OCP_USER_SDMA,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
};
/* l4_abe - timer7 */
@@ -4607,15 +4551,7 @@ static struct omap_hwmod_ocp_if
Re: omap4-panda-es boot issues with v3.15-rc4
On 05/08/2014 07:55 PM, Tony Lindgren wrote: * Kevin Hilman khil...@linaro.org [140508 08:40]: On Thu, May 8, 2014 at 8:31 AM, Kevin Hilman khil...@linaro.org wrote: Roger Quadros rog...@ti.com writes: Hi, Nishant pointed me to a booting issue with omap4-panda-es on linux-next but I'm observing similar issues, although less frequent, with v3.15-rc4 as well. Configuration: - kernel v3.15-rc4 or linux-next (20140507) - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled - u-boot/master 173d294b94cf Observations: - Out of 10 boots a few may not succeed and hang midway without any warnings. Heartbeat LED stops. e.g. http://www.hastebin.com/ebumojegoq.vhdl - Hang more noticeable on linux-next (20140507) than on v3.15-rc4 I've beeen noticing the same thing for awhile with my boot tests. For me, next-20140508 is failing most of the time now. - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even without USB_EHCI_HCD. Maybe related to when high speed interrupts occur in the boot process. - On successful boots following warning is seen [4.010375] gic_timer_retrigger: lost localtimer interrupt - On successful boots heartbeat LED stops blinking after boot process and left idle. LED can remain stuck in ON state as well. It does blink again when doing activity on console. Workaround: - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all the above issues. I don't really know what exactly is the issue but it seems to be specific to OMAP4, GIC, MPU OSWR. I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem go away. Hmm Another finger pointing in the same direction: omap2plus_defconfig + CONFIG_CPU_IDLE=y also fails to boot rather consistently in today's -next. Booting today's next with multi_v7_defconfig (so cpuidle enabled) on omap4 sdp seems to boot reliably. And it's not producing these: gic_timer_retrigger: lost localtimer interrupt while panda is producing those errors like Roger mentioned. It seems that the USB networking is the main difference between omap4 sdp and panda? Is your sdp using omap4430? To confirm 4430 vs 4460 I ran 10 tests each on omap4430 panda and omap4460 panda. 4430panda fails 2/10 times. 4460panda fails 7/10 times. cheers, -roger -- 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: omap4-panda-es boot issues with v3.15-rc4
Kevin,
On 05/09/2014 01:15 AM, Kevin Hilman wrote:
Tony Lindgren t...@atomide.com writes:
[...]
..but I think I found the cause for recent hangs on panda, just a wild
guess based on looking at the recent cpuidle patches after v3.14.
Looks like reverting 0b89e9aa2856 (cpuidle: delay enabling interrupts
until all coupled CPUs leave idle) makes booting work reliably again
on panda.
Can you guys confirm, so far no issues here after few boot tests,
but it might be too early to tell.
Reverting that makes things a bit more stable, but it still eventually
fails in the same way. For me it took 8 boots for it to eventually
fail.
However, if I build with CONFIG_CPU_IDLE=n, it becomes much more stable
(20+ boots in a row and still going.)
Can you please test with CPU_IDLE enabled but C3 disabled as in below patch?
It worked for me 10/10 boots.
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..99362ff 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -206,7 +206,12 @@ static struct cpuidle_driver omap4_idle_driver = {
.desc = CPUx OFF, MPUSS OSWR,
},
},
- .state_count = ARRAY_SIZE(omap4_idle_data),
+/*
+ * Disable C3 state since it is unstable
+ *
+ * .state_count = ARRAY_SIZE(omap4_idle_data),
+ */
+ .state_count = 2,
.safe_state_index = 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: omap4-panda-es boot issues with v3.15-rc4
Grygorii, On 05/08/2014 08:12 PM, Grygorii Strashko wrote: Hi, On 05/08/2014 06:40 PM, Kevin Hilman wrote: On Thu, May 8, 2014 at 8:31 AM, Kevin Hilman khil...@linaro.org wrote: Roger Quadros rog...@ti.com writes: Hi, Nishant pointed me to a booting issue with omap4-panda-es on linux-next but I'm observing similar issues, although less frequent, with v3.15-rc4 as well. Configuration: - kernel v3.15-rc4 or linux-next (20140507) - multi_v7_defconfig with LEDS_TRIGGER_HEARTBEAT and LEDS_GPIO enabled - u-boot/master 173d294b94cf Observations: - Out of 10 boots a few may not succeed and hang midway without any warnings. Heartbeat LED stops. e.g. http://www.hastebin.com/ebumojegoq.vhdl - Hang more noticeable on linux-next (20140507) than on v3.15-rc4 I've beeen noticing the same thing for awhile with my boot tests. For me, next-20140508 is failing most of the time now. - Hang more noticeable with USB_EHCI_HCD enabled but hang observed even without USB_EHCI_HCD. Maybe related to when high speed interrupts occur in the boot process. - On successful boots following warning is seen [4.010375] gic_timer_retrigger: lost localtimer interrupt - On successful boots heartbeat LED stops blinking after boot process and left idle. LED can remain stuck in ON state as well. It does blink again when doing activity on console. Workaround: - Disabling CPU_IDLE or even just disabling C3 (MPU OSWR) seems to fix all the above issues. I don't really know what exactly is the issue but it seems to be specific to OMAP4, GIC, MPU OSWR. I can confirm that disabling CONFIG_CPU_IDLE seems to make the problem go away. Hmm Another finger pointing in the same direction: omap2plus_defconfig + CONFIG_CPU_IDLE=y also fails to boot rather consistently in today's -next. Is it observed on OMAP4460 only? if no - it's smth new. if yes - may be some racing condition is still present. I could observe it on 4430 as well, but just less frequent. 2/10 times on 4430 vs 7/10 times on 4460. Roger, is it possible to connect debugger and check GIC distributor status (gic_dist_base_addr + GIC_DIST_CTRL) in case of failure? Sorry, I do not have a debugger with me at the moment. According to the current code (OMAP4460) it's possible that CPU0 will stuck only in case if CPU1 is kicked off from PWRDM_POWER_OFF state somehow but not by CPU0. Code assumes that CPU1 can exit from PWRDM_POWER_OFF state only when CPU0 calls clkdm_wakeup(cpu_clkdm[1]); Sorry, but I'm not able to debug it now. Stupid question, is hearbeat LED even supposed to stop blinking in C3 state? It would make a user think that the board is dead. cheers, -roger -- 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/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
On 09/05/14 02:33, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [140507 11:00]:
* Tomi Valkeinen tomi.valkei...@ti.com [140507 09:03]:
On 07/05/14 18:03, Tony Lindgren wrote:
BTW, I'm also personally fine with all five gpios showing in a single
gpios property, I'm not too exited about naming anything in DT..
I don't have a strong opinion here. I don't have much experience with
DT, especially with making bindings compatible with other ones.
I'd just forget the simple-panel, and have single gpio array.
Well if it's a don't care flag for both of us, let's try to use
the existing standard for simple-panel.txt and add mode-gpios
property. I'll post a patch for that.
Here's an updated version using enable-gpios, reset-gpios and
mode-gpios. So it follows simple-panel.txt and adds mode-gpios
that's currently specific to this panel only.
Also updated for -EPROBE_DEFER handling, tested that by changing
one of the GPIOs to be a twl4030 GPIO.
To speed things up a bit, I made the changes I suggested. Compile tested
only.
From f8360778e8bc96096cbb1793a18a8c240376ca09 Mon Sep 17 00:00:00 2001
From: Tony Lindgren t...@atomide.com
Date: Mon, 28 Apr 2014 20:22:21 -0700
Subject: [PATCH] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
Add device tree support for sharp-ls037v7dw01 panel.
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../bindings/video/sharp,ls037v7dw01.txt | 44 ++
.../omap2/displays-new/panel-sharp-ls037v7dw01.c | 95 +-
2 files changed, 136 insertions(+), 3 deletions(-)
create mode 100644
Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
new file mode 100644
index ..2a60fd9a2607
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,44 @@
+SHARP LS037V7DW01 TFT-LCD panel
+===
+
+Required properties:
+- compatible: sharp,ls037v7dw01
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin
+ this pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin
+ this pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure
+to change configuration between QVGA and VGA mode
+and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are
+considered optional with holes in the array.
+
+Example
+---
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+ compatible = sharp,ls037v7dw01;
+ power-supply = lcd_3v3;
+ enable-gpios = gpio5 24 GPIO_ACTIVE_HIGH;/* gpio152, lcd INI */
+ reset-gpios = gpio5 27 GPIO_ACTIVE_HIGH; /* gpio155, lcd RESB */
+ mode-gpios = gpio5 26 GPIO_ACTIVE_HIGH/* gpio154, lcd MO */
+ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd UD */
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+};
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
index 8adde628ad38..91eeb2ec93a8 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c
@@ -12,15 +12,18 @@
#include linux/delay.h
#include linux/gpio.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/platform_device.h
#include linux/slab.h
-
+#include linux/regulator/consumer.h
#include video/omapdss.h
#include video/omap-panel-data.h
struct panel_drv_data {
struct omap_dss_device dssdev;
struct omap_dss_device *in;
+ struct regulator *vcc;
int data_lines;
@@ -95,12 +98,21 @@ static int sharp_ls_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in-ops.dpi-set_data_lines(in, ddata-data_lines);
+ if (ddata-data_lines)
+ in-ops.dpi-set_data_lines(in, ddata-data_lines);
in-ops.dpi-set_timings(in, ddata-videomode);
+ if (ddata-vcc) {
+ r = regulator_enable(ddata-vcc);
+ if (r != 0)
+ return r;
+ }
+
r = in-ops.dpi-enable(in);
- if (r)
+ if (r) {
+ regulator_disable(ddata-vcc);
return r;
+ }
/* wait couple of
Re: [PATCH] gpio: always enable GPIO_OMAP on ARCH_OMAP
On Friday 09 May 2014 09:48:00 Linus Walleij wrote: On Mon, Apr 28, 2014 at 11:07 AM, Arnd Bergmann a...@arndb.de wrote: Commit 4df42de9d3e gpio: omap: add a GPIO_OMAP option instead of using ARCH_OMAP made it possible to build OMAP kernels without the GPIO driver, which at least on OMAP2 and OMAP3 causes build errors because of functions used by the platform power management code: arch/arm/mach-omap2/built-in.o: In function `omap_sram_idle': arch/arm/mach-omap2/pm24xx.c:129: undefined reference to `omap2_gpio_prepare_for_idle' arch/arm/mach-omap2/pm24xx.c:129: undefined reference to `omap2_gpio_resume_after_idle' We presumably always want the GPIO driver on OMAP, so this adds a slightly broader dependency and only allows disabling the driver only when no OMAP2PLUS platform is selected. However, it seems entirely reasonable to include the driver in build tests on other platforms, so we should also allow building it for COMPILE_TEST builds and select the required GENERIC_IRQ_CHIP that may not already be enabled on other platforms. Signed-off-by: Arnd Bergmann a...@arndb.de Patch applied to my devel branch, this is not a fix to Torvalds HEAD AFAICT, but a fix to v3.16? Else poke me. Yes, 3.16 is ok. 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
[PATCH v3 1/4] mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates
This patch add support for BCH16_ECC in GPMC (controller) driver:
- extend configuration space to include BCH16 registers
- extend parsing of DT binding for selecting BCH16 ecc-scheme
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 15 +++
include/linux/platform_data/mtd-nand-omap2.h | 5 +
2 files changed, 20 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index ab43755..9b27773 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -68,6 +68,9 @@
#defineGPMC_ECC_BCH_RESULT_1 0x244 /* not available on OMAP2 */
#defineGPMC_ECC_BCH_RESULT_2 0x248 /* not available on OMAP2 */
#defineGPMC_ECC_BCH_RESULT_3 0x24c /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_4 0x300 /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_5 0x304 /* not available on OMAP2 */
+#defineGPMC_ECC_BCH_RESULT_6 0x308 /* not available on OMAP2 */
/* GPMC ECC control settings */
#define GPMC_ECC_CTRL_ECCCLEAR 0x100
@@ -666,6 +669,12 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int
cs)
GPMC_BCH_SIZE * i;
reg-gpmc_bch_result3[i] = gpmc_base + GPMC_ECC_BCH_RESULT_3 +
GPMC_BCH_SIZE * i;
+ reg-gpmc_bch_result4[i] = gpmc_base + GPMC_ECC_BCH_RESULT_4 +
+ i * GPMC_BCH_SIZE;
+ reg-gpmc_bch_result5[i] = gpmc_base + GPMC_ECC_BCH_RESULT_5 +
+ i * GPMC_BCH_SIZE;
+ reg-gpmc_bch_result6[i] = gpmc_base + GPMC_ECC_BCH_RESULT_6 +
+ i * GPMC_BCH_SIZE;
}
}
@@ -1401,6 +1410,12 @@ static int gpmc_probe_nand_child(struct platform_device
*pdev,
else
gpmc_nand_data-ecc_opt =
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
+ else if (!strcmp(s, bch16))
+ if (gpmc_nand_data-elm_of_node)
+ gpmc_nand_data-ecc_opt =
+ OMAP_ECC_BCH16_CODE_HW;
+ else
+ pr_err(%s: BCH16 requires ELM support\n, __func__);
else
pr_err(%s: ti,nand-ecc-opt invalid value\n, __func__);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 3e9dd66..c2172e8 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -31,6 +31,8 @@ enum omap_ecc {
OMAP_ECC_BCH8_CODE_HW_DETECTION_SW,
/* 8-bit ECC calculation by GPMC, Error detection by ELM */
OMAP_ECC_BCH8_CODE_HW,
+ /* 16-bit ECC calculation by GPMC, Error detection by ELM */
+ OMAP_ECC_BCH16_CODE_HW
};
struct gpmc_nand_regs {
@@ -50,6 +52,9 @@ struct gpmc_nand_regs {
void __iomem*gpmc_bch_result1[GPMC_BCH_NUM_REMAINDER];
void __iomem*gpmc_bch_result2[GPMC_BCH_NUM_REMAINDER];
void __iomem*gpmc_bch_result3[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result4[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result5[GPMC_BCH_NUM_REMAINDER];
+ void __iomem*gpmc_bch_result6[GPMC_BCH_NUM_REMAINDER];
};
struct omap_nand_platform_data {
--
1.8.5.1.163.gd7aced9
--
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 v3 0/4] mtd: nand: omap: add support for BCH16_ECC
(re-sending as forgot to loop in linux-omap and Tony Lindgren t...@atomide.com) *changes v2 - v3* [PATCH v2 3/4] rebased to http://lists.infradead.org/pipermail/linux-mtd/2014-March/052655.html - no change in other patches *changes v1 - v2* rebased and cleaned on following versions of pending patches (1) [PATCH v8 0/6] mtd: nand: omap: optimized chip-ecc.correct() for H/W ECC schemes http://lists.infradead.org/pipermail/linux-mtd/2014-February/052092.html (2) [PATCH v6 0/4] mtd: nand: omap: optimize chip-ecc.calculate() for H/W ECC schemes http://lists.infradead.org/pipermail/linux-mtd/2014-February/052272.html (3) [PATCH v5 0/4] mtd: nand: omap: optimize chip-ecc.hwctl() for H/W ECC schemes http://lists.infradead.org/pipermail/linux-mtd/2014-March/052327.html (4) [PATCH v6 0/4] mtd: devices: elm: add checks ELM H/W constrains, driver code cleanup http://lists.infradead.org/pipermail/linux-mtd/2014-March/052455.html Tested on Beaglebone-LT(white) NAND cape having NAND Device with bus-width=16, block-size=256k, page-size=4k, oob-size=224 *original v1* http://lists.infradead.org/pipermail/linux-mtd/2013-July/047562.html With increase in NAND flash densities and shrinking of technology NAND flash has become more suspectible to multiple bit-flips. Thus stronger ECC schemes are required for detecting and correcting multiple simultaneous bit-flips in same NAND page. But stronger ECC schemes have large ECC syndrome which require more space in OOB/Spare. This patch add support for BCH16 ecc-scheme on OMAP NAND driver: (a) BCH16 ecc-scheme can correct 16 bit-flips per 512Bytes of data. (b) BCH16 ecc-scheme generates 26-bytes of ECC syndrome / 512B. Due to (b) this scheme can only be used with NAND devices which have enough OOB to satisfy following equation: OOBsize per page = 26 * (page-size / 512) Pekon Gupta (4): mtd: nand: omap: add support for BCH16_ECC - GPMC driver updates mtd: nand: omap: add support for BCH16_ECC - ELM driver updates mtd: nand: omap: add support for BCH16_ECC - NAND driver updates mtd: nand: omap: Documentation: How to select correct ECC scheme for your device ? .../devicetree/bindings/mtd/gpmc-nand.txt | 39 + arch/arm/mach-omap2/gpmc.c | 15 drivers/mtd/devices/elm.c | 42 ++ drivers/mtd/nand/omap2.c | 94 ++ include/linux/platform_data/elm.h | 3 +- include/linux/platform_data/mtd-nand-omap2.h | 5 ++ 6 files changed, 197 insertions(+), 1 deletion(-) -- 1.8.5.1.163.gd7aced9 -- 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 v3 2/4] mtd: nand: omap: add support for BCH16_ECC - ELM driver updates
ELM hardware engine is used to detect ECC errors for BCHx ecc-schemes
(like BCH4/BCH8/BCH16). This patch extends configuration of ELM registers
for loading of BCH16 ECC syndrome.
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/devices/elm.c | 42 +++
include/linux/platform_data/elm.h | 3 ++-
2 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/devices/elm.c
index 1fd4a0f..b4b02a1 100644
--- a/drivers/mtd/devices/elm.c
+++ b/drivers/mtd/devices/elm.c
@@ -213,6 +213,34 @@ static void elm_load_syndrome(struct elm_info *info,
val = cpu_to_be32(*(u32 *) ecc[0]) 12;
elm_write_reg(info, offset, val);
break;
+ case BCH16_ECC:
+ val = ecc[25] 0 | ecc[24] 8 |
+ ecc[23] 16 | ecc[22] 24;
+ elm_write_reg(info, offset, val);
+ offset += 4;
+ val = ecc[21] 0 | ecc[20] 8 |
+ ecc[19] 16 | ecc[18] 24;
+ elm_write_reg(info, offset, val);
+ offset += 4;
+ val = ecc[17] 0 | ecc[16] 8 |
+ ecc[15] 16 | ecc[14] 24;
+ elm_write_reg(info, offset, val);
+ offset += 4;
+ val = ecc[13] 0 | ecc[12] 8 |
+ ecc[11] 16 | ecc[10] 24;
+ elm_write_reg(info, offset, val);
+ offset += 4;
+ val = ecc[9]0 | ecc[8]8 |
+ ecc[7] 16 | ecc[6] 24;
+ elm_write_reg(info, offset, val);
+ offset += 4;
+ val = ecc[5]0 | ecc[4]8 |
+ ecc[3] 16 | ecc[2] 24;
+ elm_write_reg(info, offset, val);
+ offset += 4;
+ val = ecc[1]0 | ecc[0]8;
+ elm_write_reg(info, offset, val);
+ break;
default:
pr_err(invalid config bch_type\n);
}
@@ -435,6 +463,13 @@ static int elm_context_save(struct elm_info *info)
for (i = 0; i ERROR_VECTOR_MAX; i++) {
offset = i * SYNDROME_FRAGMENT_REG_SIZE;
switch (bch_type) {
+ case BCH16_ECC:
+ regs-elm_syndrome_fragment_6[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_6 + offset);
+ regs-elm_syndrome_fragment_5[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_5 + offset);
+ regs-elm_syndrome_fragment_4[i] = elm_read_reg(info,
+ ELM_SYNDROME_FRAGMENT_4 + offset);
case BCH8_ECC:
regs-elm_syndrome_fragment_3[i] = elm_read_reg(info,
ELM_SYNDROME_FRAGMENT_3 + offset);
@@ -473,6 +508,13 @@ static int elm_context_restore(struct elm_info *info)
for (i = 0; i ERROR_VECTOR_MAX; i++) {
offset = i * SYNDROME_FRAGMENT_REG_SIZE;
switch (bch_type) {
+ case BCH16_ECC:
+ elm_write_reg(info, ELM_SYNDROME_FRAGMENT_6 + offset,
+ regs-elm_syndrome_fragment_6[i]);
+ elm_write_reg(info, ELM_SYNDROME_FRAGMENT_5 + offset,
+ regs-elm_syndrome_fragment_5[i]);
+ elm_write_reg(info, ELM_SYNDROME_FRAGMENT_4 + offset,
+ regs-elm_syndrome_fragment_4[i]);
case BCH8_ECC:
elm_write_reg(info, ELM_SYNDROME_FRAGMENT_3 + offset,
regs-elm_syndrome_fragment_3[i]);
diff --git a/include/linux/platform_data/elm.h
b/include/linux/platform_data/elm.h
index 4edb406..ac2f266 100644
--- a/include/linux/platform_data/elm.h
+++ b/include/linux/platform_data/elm.h
@@ -21,6 +21,7 @@
enum bch_ecc {
BCH4_ECC = 0,
BCH8_ECC,
+ BCH16_ECC
};
/* ELM support 8 error syndrome process */
@@ -38,7 +39,7 @@ struct elm_errorvec {
bool error_reported;
bool error_uncorrectable;
int error_count;
- int error_loc[ERROR_VECTOR_MAX];
+ int error_loc[16];
};
void elm_decode_bch_error_page(struct device *dev, u8
[PATCH v3 4/4] mtd: nand: omap: Documentation: How to select correct ECC scheme for your device ?
- Adds DT binding property for BCH16 ECC scheme - Adds describes on factors which determine choice of ECC scheme for particular device Signed-off-by: Pekon Gupta pe...@ti.com --- .../devicetree/bindings/mtd/gpmc-nand.txt | 39 ++ 1 file changed, 39 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt index 5e1f31b..f2dbb33 100644 --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt @@ -28,6 +28,8 @@ Optional properties: ham1 1-bit Hamming ecc code bch4 4-bit BCH ecc code bch8 8-bit BCH ecc code + bch16 16-bit BCH ECC code + Refer below How to select correct ECC scheme for your device ? - ti,nand-xfer-type: A string setting the data transfer type. One of: @@ -90,3 +92,40 @@ Example for an AM33xx board: }; }; +How to select correct ECC scheme for your device ? +-- +Higher ECC scheme usually means better protection against bit-flips and +increased system lifetime. However, selection of ECC scheme is dependent +on various other factors like; +(1) Presence of supporting hardware engines on SoC. + Some legacy OMAP SoC do not have ELM h/w engine thus such SoC cannot + support BCHx_HW ECC schemes. But such SoC can support + BCHx_HW_DETECTION_SW ECC schemes which use s/w library with slight + CPU performance panalty only when too bit-flips are detected. +(2) Device parameters like OOBSIZE + Higher ECC schemes require more OOB/Spare area to store ECC. + So choice of ECC scheme is limited by NAND oobsize. In general + following expression help determine whether given device can + accomodate ECC syndrome or not: + 2 + (PAGESIZE / 512) * ECC_BYTES = OOBSIZE + where + OOBSIZE number of bytes in OOB/spare area + PAGESIZEnumber of bytes in main-area of device page + ECC_BYTES number of ECC bytes generated to protect + 512 bytes of data, which is: + '3' for HAM1_xx ecc schemes + '7' for BCH4_xx ecc schemes + '14' for BCH8_xx ecc schemes + '26' for BCH16_xx ecc schemes + + Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 + Number of spare/OOB bytes required for using BCH16 ecc-scheme + (2 + (2048 / 512) * 26) = 106 bytes is greater than OOBSIZE + (As per above table for BCH16 ecc-scheme, ECC_BYTES = 26) + Thus BCH16 cannot be supported on 2K NAND with OOBSIZE=64 bytes + + Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 + Number of spare/OOB bytes required for using BCH16 ecc-scheme + (2 + (2048 / 512) * 26) = 106 bytes is less than OOBSIZE + (As per above table for BCH16 ecc-scheme, ECC_BYTES = 26) + Thus BCH16 can be supported on 4K NAND with OOBSIZE=128 bytes -- 1.8.5.1.163.gd7aced9 -- 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 v3 3/4] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates
This patch add support for BCH16 ecc-scheme in OMAP NAND driver, by extending
following functions:
- omap_enable_hwecc (nand_chip-ecc.hwctl): configure GPMC controller
- omap_calculate_ecc_bch (nand_chip-ecc.calculate): fetch ECC signature from
GPMC controller
- omap_elm_correct_data (nand_chip-ecc.correct): detect and correct ECC
errors using ELM
(a) BCH16 ecc-scheme can detect and correct 16 bit-flips per 512Bytes of data.
(b) BCH16 ecc-scheme generates 26-bytes of ECC syndrome / 512B.
Due to (b) this scheme can only be used with NAND devices which have enough
OOB to satisfy the relation: OOBsize per page = 26 * (page-size / 512)
Signed-off-by: Pekon Gupta pe...@ti.com
---
drivers/mtd/nand/omap2.c | 94
1 file changed, 94 insertions(+)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d161c9b..c359af0 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -137,6 +137,10 @@
#define BADBLOCK_MARKER_LENGTH 2
#ifdef CONFIG_MTD_NAND_OMAP_BCH
+static u_char bch16_vector[] = {0xf5, 0x24, 0x1c, 0xd0, 0x61, 0xb3, 0xf1, 0x55,
+ 0x2e, 0x2c, 0x86, 0xa3, 0xed, 0x36, 0x1b, 0x78,
+ 0x48, 0x76, 0xa9, 0x3b, 0x97, 0xd1, 0x7a, 0x93,
+ 0x07, 0x0e};
static u_char bch8_vector[] = {0xf3, 0xdb, 0x14, 0x16, 0x8b, 0xd2, 0xbe, 0xcc,
0xac, 0x6b, 0xff, 0x99, 0x7b};
static u_char bch4_vector[] = {0x00, 0x6b, 0x31, 0xdd, 0x41, 0xbc, 0x10};
@@ -1115,6 +1119,19 @@ static void __maybe_unused omap_enable_hwecc_bch(struct
mtd_info *mtd, int mode)
ecc_size1 = BCH_ECC_SIZE1;
}
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ bch_type = 0x2;
+ nsectors = chip-ecc.steps;
+ if (mode == NAND_ECC_READ) {
+ wr_mode = 0x01;
+ ecc_size0 = 52; /* ECC bits in nibbles per sector */
+ ecc_size1 = 0; /* non-ECC bits in nibbles per sector */
+ } else {
+ wr_mode = 0x01;
+ ecc_size0 = 0; /* extra bits in nibbles per sector */
+ ecc_size1 = 52; /* OOB bits in nibbles per sector */
+ }
+ break;
default:
return;
}
@@ -1163,6 +1180,7 @@ static int __maybe_unused omap_calculate_ecc_bch(struct
mtd_info *mtd,
struct gpmc_nand_regs *gpmc_regs = info-reg;
u8 *ecc_code;
unsigned long nsectors, bch_val1, bch_val2, bch_val3, bch_val4;
+ u32 val;
int i;
nsectors = ((readl(info-reg.gpmc_ecc_config) 4) 0x7) + 1;
@@ -1202,6 +1220,41 @@ static int __maybe_unused omap_calculate_ecc_bch(struct
mtd_info *mtd,
*ecc_code++ = ((bch_val1 4) 0xFF);
*ecc_code++ = ((bch_val1 0xF) 4);
break;
+ case OMAP_ECC_BCH16_CODE_HW:
+ val = readl(gpmc_regs-gpmc_bch_result6[i]);
+ ecc_code[0] = ((val 8) 0xFF);
+ ecc_code[1] = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result5[i]);
+ ecc_code[2] = ((val 24) 0xFF);
+ ecc_code[3] = ((val 16) 0xFF);
+ ecc_code[4] = ((val 8) 0xFF);
+ ecc_code[5] = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result4[i]);
+ ecc_code[6] = ((val 24) 0xFF);
+ ecc_code[7] = ((val 16) 0xFF);
+ ecc_code[8] = ((val 8) 0xFF);
+ ecc_code[9] = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result3[i]);
+ ecc_code[10] = ((val 24) 0xFF);
+ ecc_code[11] = ((val 16) 0xFF);
+ ecc_code[12] = ((val 8) 0xFF);
+ ecc_code[13] = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result2[i]);
+ ecc_code[14] = ((val 24) 0xFF);
+ ecc_code[15] = ((val 16) 0xFF);
+ ecc_code[16] = ((val 8) 0xFF);
+ ecc_code[17] = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result1[i]);
+ ecc_code[18] = ((val 24) 0xFF);
+ ecc_code[19] = ((val 16) 0xFF);
+ ecc_code[20] = ((val 8) 0xFF);
+ ecc_code[21] = ((val 0) 0xFF);
+ val = readl(gpmc_regs-gpmc_bch_result0[i]);
+ ecc_code[22] = ((val 24) 0xFF);
+ ecc_code[23] = ((val 16) 0xFF);
+ ecc_code[24] = ((val 8) 0xFF);
+
Re: [PATCH] backlight: gpio-backlight: Fix warning when the GPIO is on a I2C chip
On Fri, May 9, 2014 at 5:42 AM, Jingoo Han jg1@samsung.com wrote: Linus Walleij, Is there any reason to keep these two functions such as gpiod_set_raw_value_cansleep() and gpiod_set_raw_value()? Yes, the former can *not* be called from interrupt context, and thus erroneous usage can be detected with runtime checks. Yours, Linus Walleij -- 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/4] OMAPDSS: Add support for panel ls037v7dw01
On 05/05/14 21:41, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140429 16:53]: Hi all, Here are few patches to add devicetree support for panel ls037v7dw01 that's found on many omap3 boards. They seem to be often mis-configured as various panel dpi entries, but really should be move to use panel ls037v7dw01 instead. This panel is found at least on the omap3 sdp, ldp, omap3 evm and few other development boards. Tomi, assuming no more comments, do you want to pick up the first three patches of this series? I can queue the .dts changes or you can also set up a separate .dts changes branch for DSS that I can merge in too. If it's all the same to you, I'd like to collect all display related arch/arm/ patches into my tree, and I'll send you a merge request when it's stable. I already have OMAP5 and AM43xx stuff there. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 0/3] Add display support for gta04 device
On 08/05/14 23:16, Marek Belisko wrote: This 3 patches adding display support for openmoko gta04 device. First patch add DT bindings for topolly td028 panel. Second add description for dss + panel and third fix panel probing when panel is compiled as module. Changes from v2: - add missing 'port' node for dpi_out endpoint (comment from Tomi Valkeinen) Changes from v1: - extend panel compatible string by 'omapdss' - add tpo-td028 panel to dss_compat_conv_list - add MODULE_ALIAS macro to properly probe panel when is compiled as module Marek Belisko (3): omapdss: panel-tpo-td028ec1: Add DT support. ARM: dts: oma3-gta04: Add display support omapdss: panel-tpo-td028ec1: Add module alias .../bindings/video/toppoly,td028ttec1.txt | 30 arch/arm/boot/dts/omap3-gta04.dts | 87 ++ arch/arm/mach-omap2/display.c | 1 + .../omap2/displays-new/panel-tpo-td028ttec1.c | 33 +++- 4 files changed, 150 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt I think this series looks fine. I'll pick it up. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
+ writel(value, base + offset);
+}
+
+static int dra7xx_pcie_link_up(struct pcie_port *pp)
+{
+ struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+ u32 reg = dra7xx_pcie_readl(dra7xx-base, PCIECTRL_DRA7XX_CONF_PHY_CS);
+
+ if (reg LINK_UP)
+ return true;
+ return false;
return reg LINK_UP;
Function int returning true. I'd change the prototype and would
return !!(reg ...);
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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 0/4] Support for Variscite OM44 modules and boards
On 06/05/14 21:02, Joachim Eastwood wrote: 1On 6 May 2014 02:15, Tony Lindgren t...@atomide.com wrote: * Joachim Eastwood manab...@gmail.com [140501 12:08]: Hello, This patch set adds support for Variscite OM44 series of system on modules and boards. There weren't many comments on v1 of this patch set so I hope this can make it into 3.16. Changes since v2: * Use OMAP IOPAD macros Patch 1: Add support for the SoM itself and the reference carrier board. Together these make the VAR-STK-OM44 dev kit. Patch 2: Add support for VAR-DVK-OM44 which is just the STK with a LCD display. Patch 3: Nodes for WLAN/BT support. Patch 4: Add quirks so that WLAN can be used. Still waiting for proper DT bindings. Since this patch set now uses the IOPAD macros a fix from Tony is need. See: https://patchwork.kernel.org/patch/4025421/ Just noted that the macro won't work while was about to apply these, sorry. So we're back to either using the existing OMAP4_WKUP_IOPAD or raw offset from the padconf area unless you have some great macro ideas. I see. I'll take another look at the macro's and see what I can come up with. Note that patch 1 relies upon a patch from Tomi Valkeinen add hpd-gpio (hotplug detect) to the hdmi-connector. See: http://marc.info/?l=linux-omapm=139771947508021w=2 Patch 2 also relies upon a patch from Tomi that adds DT support to panel-dpi. See: http://marc.info/?l=devicetreem=139030201815380w=2 Maybe also leave out the DSS changes until Tomi has confirmed those? I can split the patch set and put a patch with the DSS DT nodes at the end. Maybe this last patch can go through Tomi if he has a DSS DT branch. I don't want to drop it entirely from the patch set because some other people has expressed interest in testing it with full display and hdmi support. I have the HDMI and panel-dpi patches queued for 3.16. As this is a new board, and there's no compile time dependency on DSS stuff, I think all these patches can go through Tony. For the display related parts in these patches: Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/1] drivers/video/fbdev/omap2/dss/dss.c: add __exit to dss_uninit_ports
On 23/04/14 19:09, Fabian Frederick wrote:
dss_uninit_ports is only called by __exit omap_dsshw_remove
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: linux-omap@vger.kernel.org
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Fabian Frederick f...@skynet.be
---
drivers/video/fbdev/omap2/dss/dss.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..a1c1cc2 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -813,7 +813,7 @@ static int __init dss_init_ports(struct platform_device
*pdev)
return 0;
}
-static void dss_uninit_ports(void)
+static void __exit dss_uninit_ports(void)
{
#ifdef CONFIG_OMAP2_DSS_DPI
dpi_uninit_port();
Thanks, queued for 3.16.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [RFC 1/6] omapdss: remove check for simpler port/endpoint binding
On 08/05/14 12:15, Archit Taneja wrote:
The support for simpler port/endpoint binding was removed in the merged
version
of omapdss DT. But dss_init_ports still tries to get to an endpoint even if no
port exists. Remove this as this doesn't work.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/fbdev/omap2/dss/dss.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..31ef262 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -784,12 +784,8 @@ static int __init dss_init_ports(struct platform_device
*pdev)
return 0;
port = omapdss_of_get_next_port(parent, NULL);
- if (!port) {
-#ifdef CONFIG_OMAP2_DSS_DPI
- dpi_init_port(pdev, parent);
-#endif
+ if (!port)
return 0;
- }
do {
u32 reg;
I'll try to find time to review the rest, but I'll queue this one
already for 3.16.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] mfd: twl6040: Correct HPPLL configuration for 19.2 and 38.4 MHz mclk
When the MCLK is 19.2 or 38.4 MHz the HPPLL need to be enabled and can be put in bypass mode. This will fix HPPLL use on boards with 19.2MHz mclk. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/mfd/twl6040.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On 5/9/2014 12:55 PM, Sebastian Andrzej Siewior wrote: On 05/09/2014 08:22 AM, George Cherian wrote: Just by remodelling the dt the whole problem can be solved. I am still not convinced why we should not be doing it? Because neither ways its not the exact representation of the H/W. Ha. Now I am confused. First I assumed that the musb_am335x module is built-in only to duct-tape the bug you are seeing. So this patch never made it mainline then. The problem is as far as I remember the way the phy-core does things and should be fixed. Re-arranging does not help because you can still oops the kernel (the same oops you have now) by removing the devices manually via sysfs. Okay... So, You mean to say if I unbind the phy device and then try to remove musb_am335x module, then it will oops. Now I got it... Sebastian -- 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 -- -George -- 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/dts: am335x-evmsk enable display and lcd panel support
On 06/05/14 19:10, Tony Lindgren wrote: * Darren Etheridge detheri...@ti.com [140422 13:39]: Add the necessary nodes to enable the LCD controller and the LCD panel that is attached to the Texas Instruments AM335x EVMSK platform. Also setup the necessary pin mux within the DT file to drive the LCD connector and add the correct pinmux settings for the lcd pins to be configured to when the SoC goes into sleep state for the minimum power consumption. For the sleep mode LCD pin settings, MUX_MODE7 is chosen as this corresponds to switching the pins into input GPIO's with an internal pulldown. Which has been determined to offer the lowest power solution vs leaving the pins configured in LCD mode. Probably best that Tomi queues all the panel .dts changes into a separate immutable branch that I can merge too. This is not for OMAP DSS, but for the LCDC used in beaglebone, so there are no dependencies to any of my work. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 05/17] pci: host: pcie-dra7xx: add support for pcie-dra7xx controller
Hi Arnd,
On Wednesday 07 May 2014 03:00 PM, Arnd Bergmann wrote:
On Wednesday 07 May 2014 14:14:55 Kishon Vijay Abraham I wrote:
+static void dra7xx_pcie_enable_interrupts(struct pcie_port *pp)
+{
+struct dra7xx_pcie *dra7xx = to_dra7xx_pcie(pp);
+
+dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MAIN,
+ ~INTERRUPTS);
+dra7xx_pcie_writel(dra7xx-base,
+ PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MAIN,
INTERRUPTS);
+dra7xx_pcie_writel(dra7xx-base, PCIECTRL_DRA7XX_CONF_IRQSTATUS_MSI,
+ ~LEG_EP_INTERRUPTS ~MSI);
+
+if (IS_ENABLED(CONFIG_PCI_MSI))
+dra7xx_pcie_writel(dra7xx-base,
+ PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
MSI);
+else
+dra7xx_pcie_writel(dra7xx-base,
+ PCIECTRL_DRA7XX_CONF_IRQENABLE_SET_MSI,
+ LEG_EP_INTERRUPTS);
Doesn't this just enable one or the other? In general I'd assume you need
both INTx and MSI, at least if MSI is available.
Not sure since the programming sequence in the TRM explicitly states either
legacy interrupts or MSI interrupts should be enabled but not both.
Hmm, I think that means you can't have MSI at all. You have to support
legacy PCI devices that can't do MSI.
Do you know if you have a modern GIC implementation with MSI support
in these SoCs? It would be better anyway to use the GIC for doing
In DRA7 it is not there. I'm not sure in other platforms.
MSI, so you can just ignore the internal MSI controller here.
+static int add_pcie_port(struct dra7xx_pcie *dra7xx,
+ struct platform_device *pdev)
+{
+int ret;
+struct pcie_port *pp;
+struct resource *res;
+struct device *dev = pdev-dev;
+
+pp = dra7xx-pp;
+pp-dev = dev;
+pp-ops = dra7xx_pcie_host_ops;
+
+spin_lock_init(pp-conf_lock);
+
+pp-irq = platform_get_irq(pdev, 1);
+if (pp-irq 0) {
+dev_err(dev, missing IRQ resource\n);
+return -EINVAL;
+}
The binding does not list a mandatory interrupts property, so
this should not be treated as an error.
actually the 'interrupts' property is documented in pci/designware-pcie.txt.
Hmm, but you don't seem to use it the same way as documented there.
I'm not sure what 'level interrupt, pulse interrupt, special interrupt'
in the parent binding are, but they don't seem to be the ones you use
here.
Yeah. I'll update my Documentation. Thanks for pointing this out.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/17] pci: host: pcie-designware: Use *base-mask* for configuring the iATU
Hi, On Thursday 08 May 2014 02:48 PM, Arnd Bergmann wrote: On Thursday 08 May 2014 18:05:11 Jingoo Han wrote: On Tuesday, May 06, 2014 10:59 PM, Arnd Bergmann wrote: On Tuesday 06 May 2014 19:03:52 Kishon Vijay Abraham I wrote: In DRA7, the cpu sees 32bit address, but the pcie controller can see only 28bit address. So whenever the cpu issues a read/write request, the 4 most significant bits are used by L3 to determine the target controller. For example, the cpu reserves 0x2000_ - 0x2FFF_ for PCIe controller but the PCIe controller will see only (0x000_ - 0xFFF_FFF). So for programming the outbound translation window the *base* should be programmed as 0x000_. Whenever we try to write to say 0x2000_, it will be translated to whatever we have programmed in the translation window with base as 0x000_. Cc: Bjorn Helgaas bhelg...@google.com Cc: Marek Vasut ma...@denx.de Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Acked-by: Jingoo Han jg1@samsung.com Acked-by: Mohit Kumar mohit.ku...@st.com Sorry, but NAK. We have a standard 'dma-ranges' property to handle this, so use it. See the x-gene PCIe driver patches for an example. Please also talk to Santosh about it, as he is implementing generic support for parsing dma-ranges in platform devices at the moment. Hi Arnd, Do you mean the following patch? http://www.spinics.net/lists/kernel/msg1737725.html That is the patch Santosh did for platform devices, which is related but not what I meant here. For the PCI inbound window setup, please have a look at https://lkml.org/lkml/2014/3/19/607 For some reason lkml is not showing any contents. Do you have a different link? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/11] ARM: OMAP: OMAP5 AM43x DSS
Hi, Here are arch/arm/ patches to add display support for OMAP5 and AM43x. I have these in my tree, in a branch I will send to Tony for merging. Most of these patches have already been around the lists, but I wanted to send them one more time to verify that all looks right and everybody is fine with them. Tomi Archit Taneja (1): ARM: OMAP2+: hwmod: OMAP5 DSS hwmod data Sathya Prakash M R (4): ARM: AM43xx: hwmod: add DSS hwmod data ARM: dts: am43xx: add ti,set-rate-parent for disp_clk ARM: dts: am4372.dtsi: add DSS information ARM: dts: am437x-gp-evm: add LCD data Tomi Valkeinen (6): ARM: dts: am43x-epos-evm: add LCD data ARM: dts: omap5-clocks.dtsi: add dss iclk ARM: dts: omap5-clocks.dtsi: add ti,set-rate-parent to dss_dss_clk ARM: dts: omap5.dtsi: add DSS nodes ARM: dts: omap5-uevm.dts: add tca6424a ARM: dts: omap5-uevm.dts: add display nodes arch/arm/boot/dts/am4372.dtsi | 30 +++ arch/arm/boot/dts/am437x-gp-evm.dts| 97 ++ arch/arm/boot/dts/am43x-epos-evm.dts | 101 ++ arch/arm/boot/dts/am43xx-clocks.dtsi | 1 + arch/arm/boot/dts/omap5-uevm.dts | 89 + arch/arm/boot/dts/omap5.dtsi | 70 +++ arch/arm/boot/dts/omap54xx-clocks.dtsi | 9 + arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 104 +++ arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 + arch/arm/mach-omap2/prcm43xx.h | 1 + 10 files changed, 785 insertions(+) -- 1.9.1 -- 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 02/11] ARM: dts: am43xx: add ti,set-rate-parent for disp_clk
From: Sathya Prakash M R sath...@ti.com
disp_clk is a mux-clock, and to set the rate of the parent PLL, we need
ti,set-rate-parent flag.
Add the flag.
Signed-off-by: Sathya Prakash M R sath...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/am43xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009cc9332..144663ba7739 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -511,6 +511,7 @@
compatible = ti,mux-clock;
clocks = dpll_disp_m2_ck, dpll_core_m5_ck,
dpll_per_m2_ck;
reg = 0x4244;
+ ti,set-rate-parent;
};
dpll_extdev_ck: dpll_extdev_ck {
--
1.9.1
--
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 06/11] ARM: OMAP2+: hwmod: OMAP5 DSS hwmod data
From: Archit Taneja arc...@ti.com
Add hwmod data for dss core, dispc dsi1, dsi2, rfbi and hdmi. It's more
or less similar to omap4 hwmod data.
Signed-off-by: Archit Taneja arc...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 +
1 file changed, 283 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index 892317294fdc..e8bdd7a91090 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -334,6 +334,235 @@ static struct omap_hwmod omap54xx_dmic_hwmod = {
};
/*
+ * 'dss' class
+ * display sub-system
+ */
+static struct omap_hwmod_class_sysconfig omap54xx_dss_sysc = {
+ .rev_offs = 0x,
+ .syss_offs = 0x0014,
+ .sysc_flags = SYSS_HAS_RESET_STATUS,
+};
+
+static struct omap_hwmod_class omap54xx_dss_hwmod_class = {
+ .name = dss,
+ .sysc = omap54xx_dss_sysc,
+ .reset = omap_dss_reset,
+};
+
+/* dss */
+static struct omap_hwmod_opt_clk dss_opt_clks[] = {
+ { .role = 32khz_clk, .clk = dss_32khz_clk },
+ { .role = sys_clk, .clk = dss_sys_clk },
+ { .role = hdmi_clk, .clk = dss_48mhz_clk },
+};
+
+static struct omap_hwmod omap54xx_dss_hwmod = {
+ .name = dss_core,
+ .class = omap54xx_dss_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .context_offs = OMAP54XX_RM_DSS_DSS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .opt_clks = dss_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_opt_clks),
+};
+
+/*
+ * 'dispc' class
+ * display controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_MIDLEMODE |
+ SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ MSTANDBY_FORCE | MSTANDBY_NO | MSTANDBY_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc = omap54xx_dispc_sysc,
+};
+
+/* dss_dispc */
+static struct omap_hwmod_opt_clk dss_dispc_opt_clks[] = {
+ { .role = sys_clk, .clk = dss_sys_clk },
+};
+
+/* dss_dispc dev_attr */
+static struct omap_dss_dispc_dev_attr dss_dispc_dev_attr = {
+ .has_framedonetv_irq= 1,
+ .manager_count = 4,
+};
+
+static struct omap_hwmod omap54xx_dss_dispc_hwmod = {
+ .name = dss_dispc,
+ .class = omap54xx_dispc_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ },
+ },
+ .opt_clks = dss_dispc_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(dss_dispc_opt_clks),
+ .dev_attr = dss_dispc_dev_attr,
+};
+
+/*
+ * 'dsi1' class
+ * display serial interface controller
+ */
+
+static struct omap_hwmod_class_sysconfig omap54xx_dsi1_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_AUTOIDLE | SYSC_HAS_CLOCKACTIVITY |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class omap54xx_dsi1_hwmod_class = {
+ .name = dsi1,
+ .sysc = omap54xx_dsi1_sysc,
+};
+
+/* dss_dsi1_a */
+static struct omap_hwmod_opt_clk dss_dsi1_a_opt_clks[] = {
+ { .role = sys_clk, .clk = dss_sys_clk },
+};
+
+static struct omap_hwmod omap54xx_dss_dsi1_a_hwmod = {
+ .name = dss_dsi1,
+ .class = omap54xx_dsi1_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = dss_dss_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP54XX_CM_DSS_DSS_CLKCTRL_OFFSET,
+ .flags = HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT,
+ },
+ },
+ .opt_clks = dss_dsi1_a_opt_clks,
+ .opt_clks_cnt
[PATCH 08/11] ARM: dts: omap5-clocks.dtsi: add ti,set-rate-parent to dss_dss_clk
Add ti,set-rate-parent to dss_dss_clk so that the DSS driver can
set the rate.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index 26c02f9e92c4..b53ca885c021 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -859,6 +859,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1420;
+ ti,set-rate-parent;
};
dss_sys_clk: dss_sys_clk {
--
1.9.1
--
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 03/11] ARM: dts: am4372.dtsi: add DSS information
From: Sathya Prakash M R sath...@ti.com
Add DT data for the display subsystem for AM4372. The DSS on AM4372 is
basically OMAP3's DSS, without DSI and VENC blocks.
Signed-off-by: Sathya Prakash M R sath...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/am4372.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d1f8707ff1df..8fd413d6d14b 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -735,6 +735,36 @@
#size-cells = 1;
status = disabled;
};
+
+ dss: dss@4832a000 {
+ compatible = ti,omap3-dss;
+ reg = 0x4832a000 0x200;
+ status = disabled;
+ ti,hwmods = dss_core;
+ clocks = disp_clk;
+ clock-names = fck;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@4832a400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x4832a400 0x400;
+ interrupts = GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = disp_clk;
+ clock-names = fck;
+ };
+
+ rfbi: rfbi@4832a800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x4832a800 0x100;
+ ti,hwmods = dss_rfbi;
+ clocks = disp_clk;
+ clock-names = fck;
+ };
+
+ };
};
};
--
1.9.1
--
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 10/11] ARM: dts: omap5-uevm.dts: add tca6424a
omap5-uevm has a tca6424a I/O expander. Add it to the .dts file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3b99ec25b748..76877516f6df 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -434,6 +434,13 @@
pinctrl-0 = i2c5_pins;
clock-frequency = 40;
+
+ gpio9: gpio@22 {
+ compatible = ti,tca6424;
+ reg = 0x22;
+ gpio-controller;
+ #gpio-cells = 2;
+ };
};
mcbsp3 {
--
1.9.1
--
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 07/11] ARM: dts: omap5-clocks.dtsi: add dss iclk
Add missing DSS interface clock node.
Note: The TRM says DSS's interface clock is DSS_L3_GICLK, but it is not
clear to me from reading the TRM and looking at the
arch/arm/boot/dts/omap54xx-clocks.dtsi whether using 'l3_iclk_div' as
the parent for 'dss_l3_iclk' is the correct clock.
The clock is explicitly used only by the RFBI, and we don't have any
boards using the RFBI, so I have no means to test it.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap54xx-clocks.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/omap54xx-clocks.dtsi
b/arch/arm/boot/dts/omap54xx-clocks.dtsi
index d487fdab3921..26c02f9e92c4 100644
--- a/arch/arm/boot/dts/omap54xx-clocks.dtsi
+++ b/arch/arm/boot/dts/omap54xx-clocks.dtsi
@@ -418,6 +418,14 @@
clock-div = 1;
};
+ dss_l3_iclk: dss_l3_iclk {
+ #clock-cells = 0;
+ compatible = fixed-factor-clock;
+ clocks = l3_iclk_div;
+ clock-mult = 1;
+ clock-div = 1;
+ };
+
slimbus1_slimbus_clk: slimbus1_slimbus_clk {
#clock-cells = 0;
compatible = ti,gate-clock;
--
1.9.1
--
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 05/11] ARM: dts: am43x-epos-evm: add LCD data
Add DT data for am43x-epos-evm's LCD panel.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 101 +++
1 file changed, 101 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 167dbc8494de..9aa5af71f96f 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -19,6 +19,10 @@
model = TI AM43x EPOS EVM;
compatible = ti,am43x-epos-evm,ti,am4372,ti,am43;
+ aliases {
+ display0 = lcd0;
+ };
+
vmmcsd_fixed: fixedregulator-sd {
compatible = regulator-fixed;
regulator-name = vmmcsd_fixed;
@@ -27,6 +31,44 @@
enable-active-high;
};
+ lcd0: display {
+ compatible = osddisplays,osd057T0559-34ts, panel-dpi;
+ label = lcd;
+
+ pinctrl-names = default;
+ pinctrl-0 = lcd_pins;
+
+ /*
+* SelLCDorHDMI, LOW to select HDMI. This is not really the
+* panel's enable GPIO, but we don't have HDMI driver support
nor
+* support to switch between two displays, so using this gpio as
+* panel's enable should be safe.
+*/
+ enable-gpios = gpio2 1 GPIO_ACTIVE_HIGH;
+
+ panel-timing {
+ clock-frequency = 3300;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 210;
+ hback-porch = 16;
+ hsync-len = 30;
+ vback-porch = 10;
+ vfront-porch = 22;
+ vsync-len = 13;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+ };
+
am43xx_pinmux: pinmux@44e10800 {
cpsw_default: cpsw_default {
pinctrl-single,pins =
@@ -138,6 +180,46 @@
0x160 (PIN_INPUT | MUX_MODE7) /*
spi0_cs1.gpio0_6 */
;
};
+
+ 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 */
+ ;
+ };
+
+ lcd_pins: lcd_pins {
+ pinctrl-single,pins =
+ /* GPMC CLK - GPIO 2_1 to select LCD / HDMI */
+ 0x08C (PIN_OUTPUT_PULLUP | MUX_MODE7)
+
[PATCH 09/11] ARM: dts: omap5.dtsi: add DSS nodes
Add OMAP5 DSS nodes to omap5.dtsi.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 70
1 file changed, 70 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index f8c9855ce587..32c02cefa9a6 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -869,6 +869,76 @@
#thermal-sensor-cells = 1;
};
+
+ dss: dss@5800 {
+ compatible = ti,omap5-dss;
+ reg = 0x5800 0x80;
+ status = disabled;
+ ti,hwmods = dss_core;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,omap5-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ };
+
+ rfbi: encoder@58002000 {
+ compatible = ti,omap5-rfbi;
+ reg = 0x58002000 0x100;
+ status = disabled;
+ ti,hwmods = dss_rfbi;
+ clocks = dss_dss_clk, dss_l3_iclk;
+ clock-names = fck, ick;
+ };
+
+ dsi1: encoder@58004000 {
+ compatible = ti,omap5-dsi;
+ reg = 0x58004000 0x200,
+ 0x58004200 0x40,
+ 0x58004300 0x40;
+ reg-names = proto, phy, pll;
+ interrupts = GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_dsi1;
+ clocks = dss_dss_clk, dss_sys_clk;
+ clock-names = fck, sys_clk;
+ };
+
+ dsi2: encoder@58005000 {
+ compatible = ti,omap5-dsi;
+ reg = 0x58009000 0x200,
+ 0x58009200 0x40,
+ 0x58009300 0x40;
+ reg-names = proto, phy, pll;
+ interrupts = GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_dsi2;
+ clocks = dss_dss_clk, dss_sys_clk;
+ clock-names = fck, sys_clk;
+ };
+
+ hdmi: encoder@5806 {
+ compatible = ti,omap5-hdmi;
+ reg = 0x5804 0x400,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+ reg-names = wp, pll, phy, core;
+ interrupts = GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_hdmi;
+ clocks = dss_48mhz_clk, dss_sys_clk;
+ clock-names = fck, sys_clk;
+ };
+ };
};
};
--
1.9.1
--
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 04/11] ARM: dts: am437x-gp-evm: add LCD data
From: Sathya Prakash M R sath...@ti.com
Add DT data for am437x-gp-evm's LCD panel.
Signed-off-by: Sathya Prakash M R sath...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 97 +
1 file changed, 97 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index df8798e8bd25..350e896a0d89 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -53,6 +53,48 @@
0x0269 /* LEFT */
0x0201006c; /* DOWN */
};
+
+ aliases {
+ display0 = lcd0;
+ };
+
+ lcd0: display {
+ compatible = osddisplays,osd057T0559-34ts, panel-dpi;
+ label = lcd;
+
+ pinctrl-names = default;
+ pinctrl-0 = lcd_pins;
+
+ /*
+* SelLCDorHDMI, LOW to select HDMI. This is not really the
+* panel's enable GPIO, but we don't have HDMI driver support
nor
+* support to switch between two displays, so using this gpio as
+* panel's enable should be safe.
+*/
+ enable-gpios = gpio5 8 GPIO_ACTIVE_HIGH;
+
+ panel-timing {
+ clock-frequency = 3300;
+ hactive = 800;
+ vactive = 480;
+ hfront-porch = 210;
+ hback-porch = 16;
+ hsync-len = 30;
+ vback-porch = 10;
+ vfront-porch = 22;
+ vsync-len = 13;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+ };
};
am43xx_pinmux {
@@ -81,6 +123,47 @@
0x164 MUX_MODE0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
;
};
+
+ 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
*/
+
+ ;
+ };
+
+ lcd_pins: lcd_pins {
+ pinctrl-single,pins =
+ /* GPIO 5_8 to select LCD / HDMI */
+ 0x238 (PIN_OUTPUT_PULLUP | MUX_MODE7)
+ ;
+ };
};
i2c0 {
@@ -125,3 +208,17 @@
pinctrl-0 = mmc1_pins;
cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
};
+
+dss {
+ status = ok;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_pins;
+
+ port {
+ dpi_out: endpoint@0 {
+ remote-endpoint = lcd_in;
+ data-lines = 24;
+ };
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
[PATCH 11/11] ARM: dts: omap5-uevm.dts: add display nodes
omap5-uevm has a single HDMI output. Add the necessary display
information, including pinmuxing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 82
1 file changed, 82 insertions(+)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 76877516f6df..9ffbe71b88c3 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -183,6 +183,19 @@
;
};
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x0fc (PIN_INPUT_PULLUP | MUX_MODE0)/*
hdmi_cec.hdmi_cec */
+ 0x100 (PIN_INPUT | MUX_MODE0) /*
hdmi_ddc_scl.hdmi_ddc_scl */
+ 0x102 (PIN_INPUT | MUX_MODE0) /*
hdmi_ddc_sda.hdmi_ddc_sda */
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x0fe (PIN_INPUT_PULLDOWN | MUX_MODE6) /*
hdmi_hpd.gpio7_193 */
+ ;
+ };
};
omap5_pmx_wkup {
@@ -498,3 +511,72 @@
cpu0 {
cpu0-supply = smps123_reg;
};
+
+/ {
+ aliases {
+ display0 = hdmi0;
+ };
+
+ tpd12s015: encoder@0 {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = gpio9 0 GPIO_ACTIVE_HIGH,/* TCA6424A P01, CT CP
HPD */
+ gpio9 1 GPIO_ACTIVE_HIGH,/* TCA6424A P00, LS OE
*/
+ gpio7 1 GPIO_ACTIVE_HIGH;/* GPIO 193, HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = b;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+};
+
+dss {
+ status = ok;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo4_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
1.9.1
--
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 01/11] ARM: AM43xx: hwmod: add DSS hwmod data
From: Sathya Prakash M R sath...@ti.com
Add DSS hwmod data for AM43xx.
Signed-off-by: Sathya Prakash M R sath...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 104 +
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 105 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c2cc8083fdd..8c14db2e1e47 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
#include omap_hwmod.h
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
+#include omap_hwmod_common_data.h
+
/* IP blocks */
static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,76 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+/* Display sub system - DSS */
+
+static struct omap_hwmod_dma_info am43xx_dss_sdma_chs[] = {
+ { .name = dispc, .dma_req = 5 },
+ { .dma_req = -1 },
+};
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+ .manager_count = 1,
+ .has_framedonetv_irq= 0
+};
+
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class am43xx_dispc_hwmod_class = {
+ .name = dispc,
+ .sysc = am43xx_dispc_sysc,
+};
+
+static struct omap_hwmod am43xx_dss_core_hwmod = {
+ .name = dss_core,
+ .class = omap2_dss_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .sdma_reqs = am43xx_dss_sdma_chs,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/* display controller -dispc*/
+
+static struct omap_hwmod am43xx_dss_dispc_hwmod = {
+ .name = dss_dispc,
+ .class = am43xx_dispc_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+ .dev_attr = am43xx_dss_dispc_dev_attr,
+};
+
+/*RFBI*/
+
+static struct omap_hwmod am43xx_dss_rfbi_hwmod = {
+ .name = dss_rfbi,
+ .class = omap2_rfbi_hwmod_class,
+ .clkdm_name = dss_clkdm,
+ .main_clk = disp_clk,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = AM43XX_CM_PER_DSS_CLKCTRL_OFFSET,
+ },
+ },
+};
+
/* Interfaces */
static struct omap_hwmod_ocp_if am43xx_l3_main__l4_hs = {
.master = am33xx_l3_main_hwmod,
@@ -654,6 +726,34 @@ static struct omap_hwmod_ocp_if am43xx_l3_s__qspi = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_ocp_if am43xx_dss__l3_main = {
+ .master = am43xx_dss_core_hwmod,
+ .slave = am33xx_l3_main_hwmod,
+ .clk= disp_clk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_core_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_dispc = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_dispc_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if am43xx_l4_ls__dss_rfbi = {
+ .master = am33xx_l4_ls_hwmod,
+ .slave = am43xx_dss_rfbi_hwmod,
+ .clk= l4ls_gclk,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
am33xx_l4_wkup__synctimer,
am43xx_l4_ls__timer8,
@@ -748,6 +848,10 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[]
__initdata = {
am43xx_l4_ls__ocp2scp1,
am43xx_l3_s__usbotgss0,
am43xx_l3_s__usbotgss1,
+ am43xx_dss__l3_main,
+ am43xx_l4_ls__dss,
+ am43xx_l4_ls__dss_dispc,
+ am43xx_l4_ls__dss_rfbi,
NULL,
};
diff --git a/arch/arm/mach-omap2/prcm43xx.h b/arch/arm/mach-omap2/prcm43xx.h
index 7785be984edd..ad7b3e9977f8 100644
--- a/arch/arm/mach-omap2/prcm43xx.h
+++ b/arch/arm/mach-omap2/prcm43xx.h
@@ -142,5 +142,6 @@
#define AM43XX_CM_PER_USBPHYOCP2SCP0_CLKCTRL_OFFSET
[PATCH 0/3] rtc: omap: cleanups and dra7x support
This patch series does some cleanups on RTC driver and prepares it for DRA7x support. Applies to linux-next of 5th May. Tested on DRA7x EVM using some additional patches for platform support. RTC alarm was not tested (needs IRQ cross bar patches). Sekhar Nori (3): rtc: omap: remove multiple device id checks rtc: omap: use BIT() macro rtc: omap: add support for enabling 32khz clock drivers/rtc/rtc-omap.c | 71 ++-- 1 file changed, 45 insertions(+), 26 deletions(-) -- 1.7.10.1 -- 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/3] rtc: omap: use BIT() macro
Use BIT() macro for RTC_HAS_FEATURE defines instead of hand-writing bit masks. Use BIT() macros for register bit field definitions. While at it, fix indentation done using spaces. No functional change in this patch. Signed-off-by: Sekhar Nori nsek...@ti.com --- drivers/rtc/rtc-omap.c | 42 +- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index 70f5149..734e408 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -73,43 +73,43 @@ #define OMAP_RTC_IRQWAKEEN 0x7c /* OMAP_RTC_CTRL_REG bit fields: */ -#define OMAP_RTC_CTRL_SPLIT(17) -#define OMAP_RTC_CTRL_DISABLE (16) -#define OMAP_RTC_CTRL_SET_32_COUNTER (15) -#define OMAP_RTC_CTRL_TEST (14) -#define OMAP_RTC_CTRL_MODE_12_24 (13) -#define OMAP_RTC_CTRL_AUTO_COMP(12) -#define OMAP_RTC_CTRL_ROUND_30S(11) -#define OMAP_RTC_CTRL_STOP (10) +#define OMAP_RTC_CTRL_SPLITBIT(7) +#define OMAP_RTC_CTRL_DISABLE BIT(6) +#define OMAP_RTC_CTRL_SET_32_COUNTER BIT(5) +#define OMAP_RTC_CTRL_TEST BIT(4) +#define OMAP_RTC_CTRL_MODE_12_24 BIT(3) +#define OMAP_RTC_CTRL_AUTO_COMPBIT(2) +#define OMAP_RTC_CTRL_ROUND_30SBIT(1) +#define OMAP_RTC_CTRL_STOP BIT(0) /* OMAP_RTC_STATUS_REG bit fields: */ -#define OMAP_RTC_STATUS_POWER_UP(17) -#define OMAP_RTC_STATUS_ALARM (16) -#define OMAP_RTC_STATUS_1D_EVENT(15) -#define OMAP_RTC_STATUS_1H_EVENT(14) -#define OMAP_RTC_STATUS_1M_EVENT(13) -#define OMAP_RTC_STATUS_1S_EVENT(12) -#define OMAP_RTC_STATUS_RUN (11) -#define OMAP_RTC_STATUS_BUSY(10) +#define OMAP_RTC_STATUS_POWER_UP BIT(7) +#define OMAP_RTC_STATUS_ALARM BIT(6) +#define OMAP_RTC_STATUS_1D_EVENT BIT(5) +#define OMAP_RTC_STATUS_1H_EVENT BIT(4) +#define OMAP_RTC_STATUS_1M_EVENT BIT(3) +#define OMAP_RTC_STATUS_1S_EVENT BIT(2) +#define OMAP_RTC_STATUS_RUNBIT(1) +#define OMAP_RTC_STATUS_BUSY BIT(0) /* OMAP_RTC_INTERRUPTS_REG bit fields: */ -#define OMAP_RTC_INTERRUPTS_IT_ALARM(13) -#define OMAP_RTC_INTERRUPTS_IT_TIMER(12) +#define OMAP_RTC_INTERRUPTS_IT_ALARM BIT(3) +#define OMAP_RTC_INTERRUPTS_IT_TIMER BIT(2) /* OMAP_RTC_IRQWAKEEN bit fields: */ -#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN(11) +#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEENBIT(1) /* OMAP_RTC_KICKER values */ #defineKICK0_VALUE 0x83e70b13 #defineKICK1_VALUE 0x95a4f1e0 -#defineOMAP_RTC_HAS_KICKER 0x1 +#defineOMAP_RTC_HAS_KICKER BIT(0) /* * Few RTC IP revisions has special WAKE-EN Register to enable Wakeup * generation for event Alarm. */ -#defineOMAP_RTC_HAS_IRQWAKEEN 0x2 +#defineOMAP_RTC_HAS_IRQWAKEEN BIT(1) static void __iomem*rtc_base; -- 1.7.10.1 -- 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/3] rtc: omap: add support for enabling 32khz clock
Newer versions of OMAP RTC IP such as those found
in AM335x and DRA7x need an explicit enable of
32khz functional clock which ticks the RTC.
AM335x support was working so far because of settings
done in U-Boot. However, the DRA7x U-Boot does no
such enable of 32khz clock and this patch is need
to get the RTC to work on DRA7x at least. In general,
it is better to not depend on settings done in U-Boot.
Thanks to Lokesh Vutla for noticing this.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
drivers/rtc/rtc-omap.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 734e408..03bce13 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -96,6 +96,9 @@
#define OMAP_RTC_INTERRUPTS_IT_ALARM BIT(3)
#define OMAP_RTC_INTERRUPTS_IT_TIMER BIT(2)
+/* OMAP_RTC_OSC_REG bit fields: */
+#define OMAP_RTC_OSC_32KCLK_EN BIT(6)
+
/* OMAP_RTC_IRQWAKEEN bit fields: */
#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEENBIT(1)
@@ -111,6 +114,12 @@
*/
#defineOMAP_RTC_HAS_IRQWAKEEN BIT(1)
+/*
+ * Some RTC IP revisions (like those in AM335x and DRA7x) need
+ * the 32KHz clock to be explicitly enabled.
+ */
+#define OMAP_RTC_HAS_32KCLK_EN BIT(2)
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -319,7 +328,8 @@ static struct platform_device_id omap_rtc_devtype[] = {
},
[OMAP_RTC_DATA_AM3352_IDX] = {
.name = am3352-rtc,
- .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN |
+ OMAP_RTC_HAS_32KCLK_EN,
},
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
@@ -398,6 +408,10 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
*/
rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
+ /* enable RTC functional clock */
+ if (id_entry-driver_data OMAP_RTC_HAS_32KCLK_EN)
+ rtc_writel(OMAP_RTC_OSC_32KCLK_EN, OMAP_RTC_OSC_REG);
+
/* clear old status */
reg = rtc_read(OMAP_RTC_STATUS_REG);
if (reg (u8) OMAP_RTC_STATUS_POWER_UP) {
--
1.7.10.1
--
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/3] rtc: omap: remove multiple device id checks
Remove multiple superfluous device id checks. Since
an id_table is present in the driver probe() should
never encounter an empty device id entry. In case of
OF style match, of_match_device() returns an matching
entry.
For paranoia sake, check for device id entry once and
fail probe() if none is found. This is much better than
checking for it multiple times.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
drivers/rtc/rtc-omap.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 26de5f8..70f5149 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -352,6 +352,12 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
if (of_id)
pdev-id_entry = of_id-data;
+ id_entry = platform_get_device_id(pdev);
+ if (!id_entry) {
+ dev_err(pdev-dev, no matching device entry\n);
+ return -ENODEV;
+ }
+
omap_rtc_timer = platform_get_irq(pdev, 0);
if (omap_rtc_timer = 0) {
pr_debug(%s: no update irq?\n, pdev-name);
@@ -373,8 +379,7 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
pm_runtime_enable(pdev-dev);
pm_runtime_get_sync(pdev-dev);
- id_entry = platform_get_device_id(pdev);
- if (id_entry (id_entry-driver_data OMAP_RTC_HAS_KICKER)) {
+ if (id_entry-driver_data OMAP_RTC_HAS_KICKER) {
rtc_writel(KICK0_VALUE, OMAP_RTC_KICK0_REG);
rtc_writel(KICK1_VALUE, OMAP_RTC_KICK1_REG);
}
@@ -452,7 +457,7 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
return 0;
fail0:
- if (id_entry (id_entry-driver_data OMAP_RTC_HAS_KICKER))
+ if (id_entry-driver_data OMAP_RTC_HAS_KICKER)
rtc_writel(0, OMAP_RTC_KICK0_REG);
pm_runtime_put_sync(pdev-dev);
pm_runtime_disable(pdev-dev);
@@ -469,7 +474,7 @@ static int __exit omap_rtc_remove(struct platform_device
*pdev)
/* leave rtc running, but disable irqs */
rtc_write(0, OMAP_RTC_INTERRUPTS_REG);
- if (id_entry (id_entry-driver_data OMAP_RTC_HAS_KICKER))
+ if (id_entry-driver_data OMAP_RTC_HAS_KICKER)
rtc_writel(0, OMAP_RTC_KICK0_REG);
/* Disable the clock/module */
--
1.7.10.1
--
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/5] OMAPDSS: remove unused macros
Macros to_dss_driver() and to_dss_device() are no longer used, and the latter doesn't even work. Remove them. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- include/video/omapdss.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/include/video/omapdss.h b/include/video/omapdss.h index 6adb44534606..def9f0b739c4 100644 --- a/include/video/omapdss.h +++ b/include/video/omapdss.h @@ -964,9 +964,6 @@ int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi, bool replication, const struct omap_video_timings *mgr_timings, bool mem_to_mem); -#define to_dss_driver(x) container_of((x), struct omap_dss_driver, driver) -#define to_dss_device(x) container_of((x), struct omap_dss_device, old_dev) - int omapdss_compat_init(void); void omapdss_compat_uninit(void); -- 1.9.1 -- 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/5] OMAPDSS: remove venc_panel.c
The use of venc_panel.c was removed in
09d2e7cdebd53b7572380a215008b334ff6321a5 (OMAPDSS: VENC: remove code
related to old panel model), but the file itself was left behind. Remove
the unused file.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/fbdev/omap2/dss/venc_panel.c | 232 -
1 file changed, 232 deletions(-)
delete mode 100644 drivers/video/fbdev/omap2/dss/venc_panel.c
diff --git a/drivers/video/fbdev/omap2/dss/venc_panel.c
b/drivers/video/fbdev/omap2/dss/venc_panel.c
deleted file mode 100644
index af68cd444d7e..
--- a/drivers/video/fbdev/omap2/dss/venc_panel.c
+++ /dev/null
@@ -1,232 +0,0 @@
-/*
- * Copyright (C) 2009 Nokia Corporation
- * Author: Tomi Valkeinen tomi.valkei...@nokia.com
- *
- * VENC panel driver
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program. If not, see http://www.gnu.org/licenses/.
- */
-
-#include linux/kernel.h
-#include linux/err.h
-#include linux/io.h
-#include linux/mutex.h
-#include linux/module.h
-
-#include video/omapdss.h
-
-#include dss.h
-
-static struct {
- struct mutex lock;
-} venc_panel;
-
-static ssize_t display_output_type_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- const char *ret;
-
- switch (dssdev-phy.venc.type) {
- case OMAP_DSS_VENC_TYPE_COMPOSITE:
- ret = composite;
- break;
- case OMAP_DSS_VENC_TYPE_SVIDEO:
- ret = svideo;
- break;
- default:
- return -EINVAL;
- }
-
- return snprintf(buf, PAGE_SIZE, %s\n, ret);
-}
-
-static ssize_t display_output_type_store(struct device *dev,
- struct device_attribute *attr, const char *buf, size_t size)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- enum omap_dss_venc_type new_type;
-
- if (sysfs_streq(composite, buf))
- new_type = OMAP_DSS_VENC_TYPE_COMPOSITE;
- else if (sysfs_streq(svideo, buf))
- new_type = OMAP_DSS_VENC_TYPE_SVIDEO;
- else
- return -EINVAL;
-
- mutex_lock(venc_panel.lock);
-
- if (dssdev-phy.venc.type != new_type) {
- dssdev-phy.venc.type = new_type;
- omapdss_venc_set_type(dssdev, new_type);
- if (dssdev-state == OMAP_DSS_DISPLAY_ACTIVE) {
- omapdss_venc_display_disable(dssdev);
- omapdss_venc_display_enable(dssdev);
- }
- }
-
- mutex_unlock(venc_panel.lock);
-
- return size;
-}
-
-static DEVICE_ATTR(output_type, S_IRUGO | S_IWUSR,
- display_output_type_show, display_output_type_store);
-
-static int venc_panel_probe(struct omap_dss_device *dssdev)
-{
- /* set default timings to PAL */
- const struct omap_video_timings default_timings = {
- .x_res = 720,
- .y_res = 574,
- .pixelclock = 1350,
- .hsw= 64,
- .hfp= 12,
- .hbp= 68,
- .vsw= 5,
- .vfp= 5,
- .vbp= 41,
-
- .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
- .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
-
- .interlace = true,
- };
-
- mutex_init(venc_panel.lock);
-
- dssdev-panel.timings = default_timings;
-
- return device_create_file(dssdev-dev, dev_attr_output_type);
-}
-
-static void venc_panel_remove(struct omap_dss_device *dssdev)
-{
- device_remove_file(dssdev-dev, dev_attr_output_type);
-}
-
-static int venc_panel_enable(struct omap_dss_device *dssdev)
-{
- int r;
-
- dev_dbg(dssdev-dev, venc_panel_enable\n);
-
- mutex_lock(venc_panel.lock);
-
- if (dssdev-state != OMAP_DSS_DISPLAY_DISABLED) {
- r = -EINVAL;
- goto err;
- }
-
- omapdss_venc_set_timings(dssdev, dssdev-panel.timings);
- omapdss_venc_set_type(dssdev, dssdev-phy.venc.type);
- omapdss_venc_invert_vid_out_polarity(dssdev,
- dssdev-phy.venc.invert_polarity);
-
- r = omapdss_venc_display_enable(dssdev);
- if (r)
- goto err;
-
- dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
-
- mutex_unlock(venc_panel.lock);
-
- return 0;
-err:
-
[PATCH 1/5] OMAPDSS: Fix writes to DISPC_POL_FREQ
When omapdss writes to DISPC_POL_FREQ register, it always ORs the bits with the current contents of the register, never clearing the old ones, causing wrong signal polarity settings. As we write all the bits in DISPC_POL_FREQ, we don't need to care about the current contents of the register. So fix the issue by constructing new register value from scratch. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/fbdev/omap2/dss/dispc.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/video/fbdev/omap2/dss/dispc.c b/drivers/video/fbdev/omap2/dss/dispc.c index f18397c33e8f..a22c64e26172 100644 --- a/drivers/video/fbdev/omap2/dss/dispc.c +++ b/drivers/video/fbdev/omap2/dss/dispc.c @@ -2945,13 +2945,13 @@ static void _dispc_mgr_set_lcd_timings(enum omap_channel channel, int hsw, BUG(); } - l = dispc_read_reg(DISPC_POL_FREQ(channel)); - l |= FLD_VAL(onoff, 17, 17); - l |= FLD_VAL(rf, 16, 16); - l |= FLD_VAL(de_level, 15, 15); - l |= FLD_VAL(ipc, 14, 14); - l |= FLD_VAL(hsync_level, 13, 13); - l |= FLD_VAL(vsync_level, 12, 12); + l = FLD_VAL(onoff, 17, 17) | + FLD_VAL(rf, 16, 16) | + FLD_VAL(de_level, 15, 15) | + FLD_VAL(ipc, 14, 14) | + FLD_VAL(hsync_level, 13, 13) | + FLD_VAL(vsync_level, 12, 12); + dispc_write_reg(DISPC_POL_FREQ(channel), l); } -- 1.9.1 -- 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 5/5] Doc/DT: hdmi-connector: add HPD GPIO documentation
Add binding documentation for HDMI connector's HPD GPIO. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/video/hdmi-connector.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt index c19e2573..acd5668b1ce1 100644 --- a/Documentation/devicetree/bindings/video/hdmi-connector.txt +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt @@ -7,6 +7,7 @@ Required properties: Optional properties: - label: a symbolic name for the connector +- hpd-gpios: HPD GPIO number Required nodes: - Video port for HDMI input -- 1.9.1 -- 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 4/5] OMAPDSS: connector-hdmi: hpd support
Add support to handle HPD GPIO in the HDMI connector driver. For the
time being, the driver only uses HPD GPIO to report is the cable is
connected via detect() calll.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../fbdev/omap2/displays-new/connector-hdmi.c | 25 +-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
index 29ed21b9dce5..4420ccb69aa9 100644
--- a/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/fbdev/omap2/displays-new/connector-hdmi.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/of.h
+#include linux/of_gpio.h
#include drm/drm_edid.h
@@ -43,6 +44,8 @@ struct panel_drv_data {
struct device *dev;
struct omap_video_timings timings;
+
+ int hpd_gpio;
};
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
@@ -161,7 +164,10 @@ static bool hdmic_detect(struct omap_dss_device *dssdev)
struct panel_drv_data *ddata = to_panel_data(dssdev);
struct omap_dss_device *in = ddata-in;
- return in-ops.hdmi-detect(in);
+ if (gpio_is_valid(ddata-hpd_gpio))
+ return gpio_get_value_cansleep(ddata-hpd_gpio);
+ else
+ return in-ops.hdmi-detect(in);
}
static int hdmic_audio_enable(struct omap_dss_device *dssdev)
@@ -288,6 +294,8 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
pdata = dev_get_platdata(pdev-dev);
+ ddata-hpd_gpio = -ENODEV;
+
in = omap_dss_find_output(pdata-source);
if (in == NULL) {
dev_err(pdev-dev, Failed to find video source\n);
@@ -307,6 +315,14 @@ static int hdmic_probe_of(struct platform_device *pdev)
struct panel_drv_data *ddata = platform_get_drvdata(pdev);
struct device_node *node = pdev-dev.of_node;
struct omap_dss_device *in;
+ int gpio;
+
+ /* HPD GPIO */
+ gpio = of_get_named_gpio(node, hpd-gpios, 0);
+ if (gpio_is_valid(gpio))
+ ddata-hpd_gpio = gpio;
+ else
+ ddata-hpd_gpio = -ENODEV;
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
@@ -344,6 +360,13 @@ static int hdmic_probe(struct platform_device *pdev)
return -ENODEV;
}
+ if (gpio_is_valid(ddata-hpd_gpio)) {
+ r = devm_gpio_request_one(pdev-dev, ddata-hpd_gpio,
+ GPIOF_DIR_IN, hdmi_hpd);
+ if (r)
+ goto err_reg;
+ }
+
ddata-timings = hdmic_default_timings;
dssdev = ddata-dssdev;
--
1.9.1
--
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: omap4-panda-es boot issues with v3.15-rc4
On Fri, May 9, 2014 at 3:30 AM, Roger Quadros rog...@ti.com wrote: Stupid question, is hearbeat LED even supposed to stop blinking in C3 state? It would make a user think that the board is dead. I believe yes - we have tick suppression. else we'd be just wasting power by waking up just to blink an LED. some deeper C states need higher latencies. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: DRA7: hwmod: add entry for RTCSS
From: Lokesh Vutla lokeshvu...@ti.com
RTCSS on DRA7 provides a precise real-time clock.
Add hwmod entry for this IP.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Applies to linux-next of 5th May.
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 810c205..402ffc7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = {
};
/*
+ * 'rtcss' class
+ *
+ */
+static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = {
+ .sysc_offs = 0x0078,
+ .sysc_flags = SYSC_HAS_SIDLEMODE,
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type3,
+};
+
+static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
+ .name = rtcss,
+ .sysc = dra7xx_rtcss_sysc,
+};
+
+/* rtcss */
+static struct omap_hwmod dra7xx_rtcss_hwmod = {
+ .name = rtcss,
+ .class = dra7xx_rtcss_hwmod_class,
+ .clkdm_name = rtc_clkdm,
+ .main_clk = sys_32k_ck,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+};
+
+/*
* 'sata' class
*
*/
@@ -2354,6 +2386,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi =
{
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_per3 - rtcss */
+static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = {
+ .master = dra7xx_l4_per3_hwmod,
+ .slave = dra7xx_rtcss_hwmod,
+ .clk= l4_root_clk_div,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = {
{
.name = sysc,
@@ -2683,6 +2723,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
dra7xx_l4_cfg__mpu,
dra7xx_l4_cfg__ocp2scp1,
dra7xx_l3_main_1__qspi,
+ dra7xx_l4_per3__rtcss,
dra7xx_l4_cfg__sata,
dra7xx_l4_cfg__smartreflex_core,
dra7xx_l4_cfg__smartreflex_mpu,
--
1.7.10.1
--
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] power: twl4030_charger: clear IRQs after handling them
On 05/08/2014 08:03 PM, Tony Lindgren wrote: * Nishanth Menon n...@ti.com [140506 17:25]: Subject: [PATCH] power: twl4030_charger: detect battery presence prior to enabling charger TWL4030's Battery Charger seems to be designed for non-hotpluggable batteries. If battery is not present in the system, BATSTS is always set with the expectation that software will take actions to move to a required safe state (could be power down or disable various charger paths). It does not seem possible even by manipulating the edge detection of the event (using BCIEDR2 register) to have a consistent hotplug handling. This seems to be the result of BATSTS interrupt generated when the thermistor of the battery pack is disconnected from the dedicated ADIN1 pin. Clearing the status just results in the status being regenerated by the monitoring ADC(MADC) and disabling the edges of event just makes hotplug no longer function. The only other option is to disable the detection of the MADC by disabling BCIMFEN4::BATSTSMCHGEN (battery presence detector) - but then, we can never again detect battery reconnection. So, detect battery presence based on precharge(which is hardware automatic state) or default main charger configuration at the time of probe and enable charger logic only if battery was present. Reported-by: Russell King li...@arm.linux.org.uk Signed-off-by: Nishanth Menon n...@ti.com Gets rid of the errors for me if CONFIG_CHARGER_TWL4030=y. Looks like we don't have that enabled by default in omap2plus_defconfig which explain why it's taken so long to notice this one: Tested-by: Tony Lindgren t...@atomide.com Thanks. I will post this out to the list as formal series. -- 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 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 05/08/2014 11:22 PM, Joel Fernandes wrote:
On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[...]
Ok, thanks for pointing to the post.
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
goto found;
But then, crossbar_domain_map and crossbar_domain_unmap need hints as
well to know that there is no corresponding crossbar registers.
Have'nt thought through that yet. Looking to hear about opinions here.
[1] http://marc.info/?l=linux-arm-kernelm=139958155312421w=2
--
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] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro
On 6 May 2014 02:12, Tony Lindgren t...@atomide.com wrote: Hi, Sorry for dropping the ball on this one, got distracted with various other fixes for a while. * Joachim Eastwood manab...@gmail.com [140421 09:16]: On 21 April 2014 18:12, Joachim Eastwood manab...@gmail.com wrote: On 21 April 2014 17:35, Tony Lindgren t...@atomide.com wrote: * Joachim Eastwood manab...@gmail.com [140419 09:25]: On 19 April 2014 18:14, Joachim Eastwood manab...@gmail.com wrote: This was introduced in 43a348ea53eb5fd79 but hasn't caused any harm since it don't have any users yet. Or maybe I am confused about this macro. Tony which offset from the OMAP4 TRM should be used? Under section 18.6.8 there are is a column with address offset. Is this the number you want in the macro? Oh I see, the offsets in the TRM in this case are from the base of the wkup module padconf base instead of listing the physical address for the register. Ideally the value would be what the documentation lists in the Table 18-9. Device Wake-Up Control Module Pad Configuration Register Fields with 2 added to it for the upper registers as we're using 16-bit register address. In any case something that's relatively easy to verify against the documentation. But that seems to vary between the physical address and the offset, so we need to specify some mask there. Something like below (untested) should do the trick as long as we never have padconf reg areas larger than 0xfff. We may want to allow defining a custom mask for the macro if needed depending how the documentation is defining the mux tables for. --- a/include/dt-bindings/pinctrl/omap.h +++ b/include/dt-bindings/pinctrl/omap.h @@ -51,9 +51,9 @@ /* * Macros to allow using the absolute physical address instead of the - * padconf registers instead of the offset from padconf base. + * padconf register offset from padconf register base. */ -#define OMAP_IOPAD_OFFSET(pa, offset) (((pa) 0x) - (offset)) +#define OMAP_IOPAD_OFFSET(pa, offset) (((pa) 0xfff) - ((offset) 0xfff)) #define OMAP2420_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0030) (val) #define OMAP2430_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x2030) (val) This give the same result as my patch so it's okay for me. Checked the resulting dtb's and they are equivalent. Your patch will also have an effect on some of the others macros but I assume that is okey. Yeah looks like the above won't work as the padconf value can easily be larger than the 0xfff masked offset.. For example OMAP3_CORE1_IOPAD at 0x48002030 would become 0x030 and the value for it can be up to 0x238. And we really want the macros to behave the same way for everything rather than obfuscate the calculation even further. I guess we could add few new macros, but looks like am335x is using yet another way of documenting these so it may be endless patching. For reference my var-som-om44.dtsi now looks like this: http://slexy.org/raw/s213OvSZfF OK sorry just noticed you're using it already while was about to apply your patches. Care to update that series again to not use the macro, or by adding the offsets? hm, I'd rather add offsets than remove the macro's now. How about we introduce a mask parameter in to the OMAP_IOPAD_OFFSET macro? Something like this: #define OMAP_IOPAD_OFFSET(pa, offset, mask) (((pa) mask) - ((offset) mask)) #define OMAP4_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0040, 0xfff) (val) #define OMAP4_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0xe040, 0xfff) (val) Of course we need to fix the other users as well. One other possibility is to use my original patch in this mail or just create a OMAP4_IOPAD with offset 0x040 which will on OMAP4 work for both core and wkup. What do you think? regards Joachim Eastwood -- 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: dts: am335x-bone-common: Add i2c2 definition
On Fri 09 May 2014 12:56:23 AM CDT, Matt Ranostay wrote:
Add missing i2c2 bus define to access various cape and
prototype/breakout board devices.
Signed-off-by: Matt Ranostay mranos...@gmail.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..2aedfee 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -84,6 +84,13 @@
;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
i2c2_sda.uart1_ctsn */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
i2c2_scl.uart1_rtsn */
I dont understand the comment - i2c2_sda is being muxed to uart1_cstsn?
+ ;
+ };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins =
0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
@@ -222,6 +229,15 @@
};
+
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ status = okay;
+ clock-frequency = 40;
How did we decide on 400KHz - do all all i2c2 devices on ALL capes
work in full speed? OR should we consider a conservative 100KHz?
+};
+
/include/ tps65217.dtsi
tps {
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am33xx: Move the cppi41dma node so it's probed early
On 09 May 09:25 AM, Sebastian Andrzej Siewior wrote: On 05/09/2014 08:22 AM, George Cherian wrote: Just by remodelling the dt the whole problem can be solved. I am still not convinced why we should not be doing it? Because neither ways its not the exact representation of the H/W. Ha. Now I am confused. First I assumed that the musb_am335x module is built-in only to duct-tape the bug you are seeing. So this patch never made it mainline then. Mainline panics easily upon module removal: $ modprobe musb_am335x $ modprobe musb_dsps Here you insert something to the USB $ modprobe musb_am335x -r ... bang! the kernel panics. It works fine if you remove the musb_dsps and musb_am335x in that order, but the dependency is not enforced anywhere. So I guess preventing the module removal should be fine for now. In that case, mind testing/acking/whatever this patch: http://www.spinics.net/lists/linux-usb/msg107244.html Regards, -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
On 05/08/2014 11:22 PM, Joel Fernandes wrote:
On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[...]
Ok, thanks for pointing to the post.
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
We can't do add a flag to generic interrupt controller flags since its
very specific to cross-bar.
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
goto found;
But then, crossbar_domain_map and crossbar_domain_unmap need hints as
well to know that there is no corresponding crossbar registers.
Have'nt thought through that yet. Looking to hear about opinions here.
May be we need additional property like reserved to take care of 1:1
map.
ti,irqs-direct-map = 131 132;
--
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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
Hi Nishanth,
On 05/09/2014 07:54 AM, Nishanth Menon wrote:
[..]
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
I would pick something smaller like GIC_SKIP_CROSSBAR.
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
Sounds good, one problem I see here though is once you do the xlate, the
information that the IRQ number is GIC cross bar is lost because you are
0'ing bit 31. Then how will map/unmap decide if it needs to be crossbar
mapped/unmapped or GIC?
Perhaps, the info in bit 31 should be stored somewhere and reused later
during map time, or I am missing something.
thanks,
-Joel
--
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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 05/09/2014 08:27 AM, Santosh Shilimkar wrote:
On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
On 05/08/2014 11:22 PM, Joel Fernandes wrote:
On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[...]
Ok, thanks for pointing to the post.
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
We can't do add a flag to generic interrupt controller flags since its
very specific to cross-bar.
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
goto found;
But then, crossbar_domain_map and crossbar_domain_unmap need hints as
well to know that there is no corresponding crossbar registers.
Have'nt thought through that yet. Looking to hear about opinions here.
May be we need additional property like reserved to take care of 1:1
map.
ti,irqs-direct-map = 131 132;
We already have equivalents for these - reserved and skip. Problem is
how does crossbar driver know the difference between direct maps and
crossbar value?
6 is one of those reserved ones. dts for a device says:
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
Now, xlate gets intspec[1] = 6. 6 is valid crossbar number
PRM_IRQ_MPU, however GIC 6 is mapped to WD_TIMER_MPU_C1_IRQ_WARN -
you need to be able to get a hint that this is direct mapping dts
intended.
in the 6 example:
How do i get PRM_IRQ_MPU?
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
How do I get WD_TIMER_MPU_C1_IRQ_WARN?
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH ? - that wont work as
crossbar driver thinks it is crossbar 6 (PRM_IRQ_MPU)
--
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 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 05/09/2014 08:36 AM, Joel Fernandes wrote:
Hi Nishanth,
On 05/09/2014 07:54 AM, Nishanth Menon wrote:
[..]
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
I would pick something smaller like GIC_SKIP_CROSSBAR.
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
Sounds good, one problem I see here though is once you do the xlate, the
information that the IRQ number is GIC cross bar is lost because you are
0'ing bit 31. Then how will map/unmap decide if it needs to be crossbar
mapped/unmapped or GIC?
Correcting myself here, I meant IRQ number is GIC cross bar skipped.
--
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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 05/09/2014 08:36 AM, Joel Fernandes wrote:
Hi Nishanth,
On 05/09/2014 07:54 AM, Nishanth Menon wrote:
[..]
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
I would pick something smaller like GIC_SKIP_CROSSBAR.
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
Sounds good, one problem I see here though is once you do the xlate, the
information that the IRQ number is GIC cross bar is lost because you are
0'ing bit 31. Then how will map/unmap decide if it needs to be crossbar
mapped/unmapped or GIC?
Perhaps, the info in bit 31 should be stored somewhere and reused later
during map time, or I am missing something.
no, you did not miss anything - I did mention in my mail precisely
that But then, crossbar_domain_map and crossbar_domain_unmap need
hints as well to know that there is no corresponding crossbar
registers. Have'nt thought through that yet.
Lets discuss hardware description problem(dts) first and then solve
the driver problem next.
--
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 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 05/09/2014 08:27 AM, Santosh Shilimkar wrote:
On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
On 05/08/2014 11:22 PM, Joel Fernandes wrote:
On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[...]
Ok, thanks for pointing to the post.
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
We can't do add a flag to generic interrupt controller flags since its
very specific to cross-bar.
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
goto found;
But then, crossbar_domain_map and crossbar_domain_unmap need hints as
well to know that there is no corresponding crossbar registers.
Have'nt thought through that yet. Looking to hear about opinions here.
May be we need additional property like reserved to take care of 1:1
map.
ti,irqs-direct-map = 131 132;
That wont work for cases where the cross bar has hardware bugs as
Nishanth pointed in his example.
For such cases, you need to differentiate between a direct-map GIC IRQ
and a regular working logical cross-bar number.
For example, what if IRQ no 10 has a crossbar bug? Does this mean you
will also make crossbar number (not IRQ no, logical cross bar no) also
suffer?
The way to fix this is like Nishanth pointed by introducing some
encoding or flag:
For someone using the logical cross bar, they would say:
interrupts = GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH
and in the same dts, for someone else who is using the direct-mapped
buggy IRQ 10, they would use the the PASSTHROUGH flag:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
In this case, a direct-map list as you suggested doesn't work.
thanks,
-Joel
--
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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On Friday 09 May 2014 09:36 AM, Nishanth Menon wrote:
On 05/09/2014 08:27 AM, Santosh Shilimkar wrote:
On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
On 05/08/2014 11:22 PM, Joel Fernandes wrote:
On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[...]
Ok, thanks for pointing to the post.
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
We can't do add a flag to generic interrupt controller flags since its
very specific to cross-bar.
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
goto found;
But then, crossbar_domain_map and crossbar_domain_unmap need hints as
well to know that there is no corresponding crossbar registers.
Have'nt thought through that yet. Looking to hear about opinions here.
May be we need additional property like reserved to take care of 1:1
map.
ti,irqs-direct-map = 131 132;
We already have equivalents for these - reserved and skip. Problem is
how does crossbar driver know the difference between direct maps and
crossbar value?
6 is one of those reserved ones. dts for a device says:
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
Now, xlate gets intspec[1] = 6. 6 is valid crossbar number
PRM_IRQ_MPU, however GIC 6 is mapped to WD_TIMER_MPU_C1_IRQ_WARN -
you need to be able to get a hint that this is direct mapping dts
intended.
in the 6 example:
How do i get PRM_IRQ_MPU?
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
How do I get WD_TIMER_MPU_C1_IRQ_WARN?
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH ? - that wont work as
crossbar driver thinks it is crossbar 6 (PRM_IRQ_MPU)
Looks like I am missing something. Is the issue because of SPI offset (32)
which makes above confusion ?
--
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/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 05/09/2014 08:45 AM, Santosh Shilimkar wrote:
On Friday 09 May 2014 09:36 AM, Nishanth Menon wrote:
On 05/09/2014 08:27 AM, Santosh Shilimkar wrote:
On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
On 05/08/2014 11:22 PM, Joel Fernandes wrote:
On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[...]
Ok, thanks for pointing to the post.
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
We can't do add a flag to generic interrupt controller flags since its
very specific to cross-bar.
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
goto found;
But then, crossbar_domain_map and crossbar_domain_unmap need hints as
well to know that there is no corresponding crossbar registers.
Have'nt thought through that yet. Looking to hear about opinions here.
May be we need additional property like reserved to take care of 1:1
map.
ti,irqs-direct-map = 131 132;
We already have equivalents for these - reserved and skip. Problem is
how does crossbar driver know the difference between direct maps and
crossbar value?
6 is one of those reserved ones. dts for a device says:
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
Now, xlate gets intspec[1] = 6. 6 is valid crossbar number
PRM_IRQ_MPU, however GIC 6 is mapped to WD_TIMER_MPU_C1_IRQ_WARN -
you need to be able to get a hint that this is direct mapping dts
intended.
in the 6 example:
How do i get PRM_IRQ_MPU?
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
How do I get WD_TIMER_MPU_C1_IRQ_WARN?
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH ? - that wont work as
crossbar driver thinks it is crossbar 6 (PRM_IRQ_MPU)
Looks like I am missing something. Is the issue because of SPI offset (32)
which makes above confusion ?
The way we modelled crossbar is that the irqchip is GIC and routable
mapper is crossbar - which makes sense. now for every interrupts
description we try to find a map using the crossbar driver as the irq
framework rightly identifies that peripheral interrupts are routable
and crossbar driver is the guy who knows how to map these to a proper
GIC interrupt number. So far, we are good.
Now the trouble starts when our hardware description in dts assumes
that every peripheral interrupt is a routable interrupt - as this
thread describes - that is NOT the case.
Now the question is how do you differentiate?
interrupts = GIC_SPI Number Level
GIC_SPI is correct since we are attempting to describe the SPI
interrupt (offset what ever it is, is a NOP from conceptual discussion).
Level is fine as well.
Number: what does this indicate? crossbar number is what we have
assumed so far. however, then you loose the ability to describe
interrupts on GIC SPI which dont have crossbar interrupts.
Question is how do we differentiate between the two?
--
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 3/5] irqchip: crossbar: Skip some irqs from getting mapped to crossbar
On 05/09/2014 09:00 AM, Nishanth Menon wrote:
On 05/09/2014 08:45 AM, Santosh Shilimkar wrote:
On Friday 09 May 2014 09:36 AM, Nishanth Menon wrote:
On 05/09/2014 08:27 AM, Santosh Shilimkar wrote:
On Friday 09 May 2014 08:54 AM, Nishanth Menon wrote:
On 05/08/2014 11:22 PM, Joel Fernandes wrote:
On Thu, May 8, 2014 at 7:25 PM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
[...]
Ok, thanks for pointing to the post.
Yep - thanks Santosh for clarifying this. Now, we still have the
issues that I pointed out in [1] - without resolving which, we should
not enable crossbar for dra74x/72x.
A. taking example of PMU
interrupts = GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH
this wont work. instead the crossbar driver needs some sort of a hint
to know that it should not map these on crossbar register instead
assign GIC mapping directly.
I propose doing the following
#define GIC_CROSSBAR_PASSTHROUGH(irq_no) ((irq_no) | (0x1 31))
and dts will define the following:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(131) IRQ_TYPE_LEVEL_HIGH
This will also work for the other cases (B.2, B.3)
For B.2: L3_APP_IRQ:
instead of:
interrupts = GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH
we do:
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(10) IRQ_TYPE_LEVEL_HIGH
For B.3: NMI
interrupts = GIC_SPI GIC_CROSSBAR_PASSTHROUGH(133) IRQ_TYPE_LEVEL_HIGH
We can't do add a flag to generic interrupt controller flags since its
very specific to cross-bar.
xlate is easy -
diff --git a/drivers/irqchip/irq-crossbar.c
b/drivers/irqchip/irq-crossbar.c
index de021638..fd09ab4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -112,6 +112,10 @@ static int crossbar_domain_xlate(struct
irq_domain *d,
{
unsigned long ret;
+ /* Check to see if direct GIC mapping is required */
+ if (intspec[1] BIT(31))
+ return intspec[1] ~BIT[31];
+
ret = get_prev_map_irq(intspec[1]);
if (!IS_ERR_VALUE(ret))
goto found;
But then, crossbar_domain_map and crossbar_domain_unmap need hints as
well to know that there is no corresponding crossbar registers.
Have'nt thought through that yet. Looking to hear about opinions here.
May be we need additional property like reserved to take care of 1:1
map.
ti,irqs-direct-map = 131 132;
We already have equivalents for these - reserved and skip. Problem is
how does crossbar driver know the difference between direct maps and
crossbar value?
6 is one of those reserved ones. dts for a device says:
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
Now, xlate gets intspec[1] = 6. 6 is valid crossbar number
PRM_IRQ_MPU, however GIC 6 is mapped to WD_TIMER_MPU_C1_IRQ_WARN -
you need to be able to get a hint that this is direct mapping dts
intended.
in the 6 example:
How do i get PRM_IRQ_MPU?
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH
How do I get WD_TIMER_MPU_C1_IRQ_WARN?
interrupts = GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH ? - that wont work as
crossbar driver thinks it is crossbar 6 (PRM_IRQ_MPU)
Looks like I am missing something. Is the issue because of SPI offset (32)
which makes above confusion ?
The way we modelled crossbar is that the irqchip is GIC and routable
mapper is crossbar - which makes sense. now for every interrupts
description we try to find a map using the crossbar driver as the irq
framework rightly identifies that peripheral interrupts are routable
and crossbar driver is the guy who knows how to map these to a proper
GIC interrupt number. So far, we are good.
Now the trouble starts when our hardware description in dts assumes
that every peripheral interrupt is a routable interrupt - as this
thread describes - that is NOT the case.
Now the question is how do you differentiate?
interrupts = GIC_SPI Number Level
GIC_SPI is correct since we are attempting to describe the SPI
interrupt (offset what ever it is, is a NOP from conceptual discussion).
Level is fine as well.
Number: what does this indicate? crossbar number is what we have
assumed so far. however, then you loose the ability to describe
interrupts on GIC SPI which dont have crossbar interrupts.
Question is how do we differentiate between the two?
IMO even the direct-mapped ones can go come from a list, trouble is with
the buggy hardware hard-coded mappings which map some random crossbar to
some random GIC and can't be changed.
Only way to handle this is with a sort of an associative map in DT, not
a list. But that's far more overkill than anyone could imagine, and the
suggestion to set BIT 31 is cleaner without needing any lists at all,
while hiding all the complexity within the crossbar driver. After xlate,
the IRQ number is corrected, so the flag disappears, and the info that
its DIRECT can be stored to retrieved later during map/unmap.
thanks,
-Joel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
RE: [PATCH] usb: dwc3: ep0: fix delayed status is queued too early
On Thu, 8 May 2014, Paul Zimmerman wrote: That doesn't handle the problem I described above. When the dwc3 driver gets the late delayed status response, it will think it is a response to the new SETUP packet, and so it will carry out a bogus transfer. It won't know that the status request was meant to be a response to a defunct control transfer. I think you misunderstood me. What I meant was, once the DWC3 controller sees the next SETUP packet, it will still accept the commands from the dwc3 driver to start the DATA and STATUS phases for the previous Control transfer, and will send back (fake) completion events for those commands to the driver. But it won't actually send anything on the wire. I see. The hardware keeps track of which transfer is being acted on. So it should be impossible for the dwc3 driver to carry out a bogus transfer. This is a feature of the DWC3 controller intended to simplify what the software needs to handle, and to automatically take care of the corner cases involved here. For other controllers that can't do this, maybe it should be handled in the UDC driver rather than in the composite gadget? The only place this can be handled properly is in the gadget driver: composite.c for those gadgets using it, otherwise in the higher level driver (if there are any remaining gadgets that don't use the composite framework). Why can't the UDC drivers handle this? AFAIK they all keep track of which phase of a Control transfer they are in. If they see another SETUP packet arrive, they could fake the DATA/STATUS stages of the previous transfer, before passing on the next SETUP packet to the gadget driver. Similar to what the DWC3 controller does in hardware. That would be possible, yes. Although, I guess it would be simpler to do it once in composite.c, instead of in each individual UDC driver. But there would have to be a quirk or something, to disable the code if the dwc3 driver is in use. And that wouldn't fix the problem for gadgets that don't use composite.c. Would the dwc3 driver really need such a quirk? From what you said before, I got the impression that if a new SETUP packet arrived before the old transfer was complete, dwc3 wouldn't inform the gadget driver about it. It would wait until the gadget driver submitted its status response for the old transfer and _then_ tell it about the new SETUP. As for gadgets not using the composite framework, I don't think there are very many of them left. gadgetfs certainly, but hardly any others. Felipe should know for sure. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
* Tomi Valkeinen tomi.valkei...@ti.com [140509 00:39]:
On 30/04/14 02:52, Tony Lindgren wrote:
Otherwise we can get often errors like the following and the
display won't come on:
omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay
omapdss APPLY error: SYNC_LOST on channel lcd, restarting
the output with video overlays disabled
There are some earlier references to this issue:
http://www.spinics.net/lists/linux-omap/msg59511.html
http://www.spinics.net/lists/linux-omap/msg59724.html
Those don't sound like the same issue, but it's hard to say. What kind
of clock rates do you get? Cat you paste debugfs/omapdss/clk, with and
without this patch?
Without this patch:
# cat /sys/kernel/debug/omapdss/clk
[ 24.833831] DSS: dss_runtime_get
[ 24.837554] DSS: dss_runtime_put
[ 24.840972] DISPC: dispc_runtime_get
[ 24.844757] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 5760
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck 5760
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck 5760lck div 1
pck 1920pck div 3
With this patch:
# cat /sys/kernel/debug/omapdss/clk
[ 34.580688] DSS: dss_runtime_get
[ 34.584197] DSS: dss_runtime_put
[ 34.587768] DISPC: dispc_runtime_get
[ 34.591552] DISPC: dispc_runtime_put
- DSS -
DSS_FCK (DSS1_ALWON_FCLK) = 10800
- DISPC -
dispc fclk source = DSS_FCK (DSS1_ALWON_FCLK)
fck 10800
- LCD -
LCD clk source = DSS_FCK (DSS1_ALWON_FCLK)
lck 10800 lck div 1
pck 1800pck div 6
What resolution do you have? If it's a very high resolution (say, DVI
output to a monitor), it could just be an issue of
not-enough-memory-bandwidth.
This is just the 3730-evm with the Sharp VGA panel mentioned in
this series.
It seems that it's safe to set the lower values even for 3630.
If we can confirm that 3630 works with the higher values
reliably we can add further detection.
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/video/fbdev/omap2/dss/dss.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dss.c
b/drivers/video/fbdev/omap2/dss/dss.c
index d55266c..ad6561f 100644
--- a/drivers/video/fbdev/omap2/dss/dss.c
+++ b/drivers/video/fbdev/omap2/dss/dss.c
@@ -707,9 +707,10 @@ static const struct dss_features omap34xx_dss_feats
__initconst = {
.dpi_select_source = dss_dpi_select_source_omap2_omap3,
};
+/* Supposedly 3630 can use div 32 mult 2, but that needs to be rechecked */
static const struct dss_features omap3630_dss_feats __initconst = {
- .fck_div_max= 32,
- .dss_fck_multiplier = 1,
+ .fck_div_max= 16,
+ .dss_fck_multiplier = 2,
These values tell about the clock hardware, they are not settings that
can be changed to change the clock. OMAP3630 has a fixed x2 multiplier
and a divider with maximum value of 16.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Fix DSS clock multiplier issue on 3703 and probably 3630
* Tomi Valkeinen tomi.valkei...@ti.com [140509 01:02]: On 09/05/14 02:20, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140429 16:53]: Otherwise we can get often errors like the following and the display won't come on: omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay omapdss APPLY error: SYNC_LOST on channel lcd, restarting the output with video overlays disabled There are some earlier references to this issue: http://www.spinics.net/lists/linux-omap/msg59511.html http://www.spinics.net/lists/linux-omap/msg59724.html It seems that it's safe to set the lower values even for 3630. If we can confirm that 3630 works with the higher values reliably we can add further detection. BTW, I'm also seeing this warning on 3730-evm it may be related: [3.523101] [ cut here ] [3.528015] WARNING: CPU: 0 PID: 6 at drivers/video/fbdev/omap2/dss/dss.c:483 dss_set_fck_rate+0x6c/0x8c() [3.538360] clk rate mismatch: 10800 != 11520 [3.543518] Modules linked in: Hmm... Can you paste the clk_summary from debugfs? Somehow the clock framework calculates the clock rate differently than the dss. Or do we have different clock.dts files used for 3730 and 3630? OK pasted to the other email in this thread. 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/dts: am335x-evmsk enable display and lcd panel support
Tomi Valkeinen tomi.valkei...@ti.com wrote on Fri [2014-May-09 14:29:02 +0300]: On 06/05/14 19:10, Tony Lindgren wrote: * Darren Etheridge detheri...@ti.com [140422 13:39]: Add the necessary nodes to enable the LCD controller and the LCD panel that is attached to the Texas Instruments AM335x EVMSK platform. Also setup the necessary pin mux within the DT file to drive the LCD connector and add the correct pinmux settings for the lcd pins to be configured to when the SoC goes into sleep state for the minimum power consumption. For the sleep mode LCD pin settings, MUX_MODE7 is chosen as this corresponds to switching the pins into input GPIO's with an internal pulldown. Which has been determined to offer the lowest power solution vs leaving the pins configured in LCD mode. Probably best that Tomi queues all the panel .dts changes into a separate immutable branch that I can merge too. This is not for OMAP DSS, but for the LCDC used in beaglebone, so there are no dependencies to any of my work. Benoit had always queued these LCDC dts patches in the past. This is exactly the same as what had been done for AM335x-EVM and AM335x-BeagleBone both of which are already in the mainline kernel. I had just missed the EVMSK previously. Darren -- 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: am335x-evm: fix comments for lcd pins
From: Wolfram Sang w...@sang-engineering.com
In the comments, LCD pins 16-23 were numbered in the wrong order.
Fix this and use proper pinmux constants for all entries while we are
Signed-off-by: Wolfram Sang w...@sang-engineering.com
Cc: Benoit Parrot bpar...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 56
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 6028217ace0f..1b642f1cd469 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -268,34 +268,34 @@
lcd_pins_s0: lcd_pins_s0 {
pinctrl-single,pins =
- 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT | MODE1
*/
- 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT | MODE1
*/
- 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT | MODE1
*/
- 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT | MODE1
*/
- 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT | MODE1
*/
- 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT | MODE1
*/
- 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT | MODE1
*/
- 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT | MODE1
*/
- 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT | MODE0
*/
- 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT | MODE0
*/
- 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT | MODE0
*/
- 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT | MODE0
*/
- 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT | MODE0
*/
- 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT | MODE0
*/
- 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT | MODE0
*/
- 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT | MODE0
*/
- 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT | MODE0
*/
- 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT | MODE0
*/
- 0xc8 0x00 /* lcd_data10.lcd_data10, OUTPUT |
MODE0 */
- 0xcc 0x00 /* lcd_data11.lcd_data11, OUTPUT |
MODE0 */
- 0xd0 0x00 /* lcd_data12.lcd_data12, OUTPUT |
MODE0 */
- 0xd4 0x00 /* lcd_data13.lcd_data13, OUTPUT |
MODE0 */
- 0xd8 0x00 /* lcd_data14.lcd_data14, OUTPUT |
MODE0 */
- 0xdc 0x00 /* lcd_data15.lcd_data15, OUTPUT |
MODE0 */
- 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT | MODE0
*/
- 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT | MODE0
*/
- 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT | MODE0 */
- 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en,
OUTPUT | MODE0 */
+ 0x20 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad8.lcd_data23 */
+ 0x24 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad9.lcd_data22 */
+ 0x28 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad10.lcd_data21 */
+ 0x2c (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad11.lcd_data20 */
+ 0x30 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad12.lcd_data19 */
+ 0x34 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad13.lcd_data18 */
+ 0x38 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad14.lcd_data17 */
+ 0x3c (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad15.lcd_data16 */
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data0.lcd_data0 */
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data1.lcd_data1 */
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data2.lcd_data2 */
+ 0xac (PIN_OUTPUT | MUX_MODE0) /*
lcd_data3.lcd_data3 */
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data4.lcd_data4 */
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data5.lcd_data5 */
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data6.lcd_data6 */
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data7.lcd_data7 */
+ 0xc0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data8.lcd_data8 */
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data9.lcd_data9 */
+ 0xc8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data10.lcd_data10 */
+ 0xcc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data11.lcd_data11 */
+ 0xd0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data12.lcd_data12 */
+
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen tomi.valkei...@ti.com [140509 01:31]: On 09/05/14 02:33, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140507 11:00]: * Tomi Valkeinen tomi.valkei...@ti.com [140507 09:03]: On 07/05/14 18:03, Tony Lindgren wrote: BTW, I'm also personally fine with all five gpios showing in a single gpios property, I'm not too exited about naming anything in DT.. I don't have a strong opinion here. I don't have much experience with DT, especially with making bindings compatible with other ones. I'd just forget the simple-panel, and have single gpio array. Well if it's a don't care flag for both of us, let's try to use the existing standard for simple-panel.txt and add mode-gpios property. I'll post a patch for that. Here's an updated version using enable-gpios, reset-gpios and mode-gpios. So it follows simple-panel.txt and adds mode-gpios that's currently specific to this panel only. Also updated for -EPROBE_DEFER handling, tested that by changing one of the GPIOs to be a twl4030 GPIO. To speed things up a bit, I made the changes I suggested. Compile tested only. OK thanks did not get the penguin with it so need to look at it a bit more. 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 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
* Tomi Valkeinen tomi.valkei...@ti.com [140509 00:08]:
On 09/05/14 02:36, Tony Lindgren wrote:
--- /dev/null
+++ b/arch/arm/boot/dts/omap-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
This looks very board specific to me... The regulator and the use of
mcspi1 depend on the board, so this file can't be used on just any omap
board with the same panel. And this can (probably) only be used on
boards with a single display. Do those boards have tv-out?
Yes there's also TV out and DVI on omap3-evm, LDP just has DVI.
It seems that all omap3 boards using this are pretty much wired
the same way.
So I have nothing against having common files, but shouldn't this be
named something more specific? If the boards involved are TI's OMAP3
development boards, maybe this should be something like...
omap3-ti-dev-panel-sharp-ls037v7dw01.dtsi. Well, that's a quite long one.
Yeah let's use omap3-panel-sharp-ls037v7dw01.dtsi. Looking at the
legacy board files that should cover quite a few of them.
I guess it might also work on 2430sdp, but let's assume omap3
for now.
+/ {
+ aliases {
+ display0 = lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = gpio-backlight;
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = regulator-fixed;
+ regulator-name = lcd_3v3;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ startup-delay-us = 7;
+ regulator-always-on;
Why always-on?
Oops, yeah that should not be there. The GPIO is board specific.
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 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen tomi.valkei...@ti.com [140509 00:24]:
On 09/05/14 02:33, Tony Lindgren wrote:
+Example when connected to a omap2+ based device:
+
+ lcd0: display {
+ compatible = sharp,ls037v7dw01;
+ power-supply = lcd_3v3;
+ enable-gpios = gpio5 24 GPIO_ACTIVE_HIGH;/* gpio152, lcd
INI */
+ reset-gpios = gpio5 27 GPIO_ACTIVE_HIGH; /* gpio155, lcd
RESB */
+ mode-gpios = gpio5 26 GPIO_ACTIVE_HIGH/* gpio154, lcd
MO */
+ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd
LR */
+ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd
UD */
+
+ panel-timing {
+ clock-frequency = 1920;
+ hback-porch = 28;
+ hactive = 480;
+ hfront-porch = 1;
+ hsync-len = 2;
+ vback-porch = 1;
+ vactive = 640;
+ vfront-porch = 1;
+ vsync-len = 1;
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
I don't think we should define panel-timing here. We know it's
sharp,ls037v7dw01, so the driver knows the video timings. Also, if we
would extend the driver to support both resolution modes, it needs to
support two different timings, so the above doesn't work in that case
either.
OK. It seems we can have at least two different timings for this panel,
the VGA timing above and the QVGA timings that LDP uses that are listed
in the .dts changes.
Although if the MO gpio is not controlled by the driver, we should tell
the driver whether that gpio is high or low.
What do you have in mind for telling that? We should also tell the
orientation of the panel:
EVM VGA omapfb.rotate=3
LDP QVGAomapfb.rotate=0
Do you have something in mind for that?
At the moment our display drivers are OMAP specific, and for that reason
we should prefix the compatible strings with omapdss,. For example,
drivers/video/fbdev/omap2/displays-new/panel-dsi-cm.c:
{ .compatible = omapdss,panel-dsi-cm, },
But we should still have the right compatible string in the .dts, so we
convert the compatible name in arch/arm/mach-omap2/display.c, with
'dss_compat_conv_list' array, to which this panel's name should be added.
Oh so what do you want to have in the .dts file then?
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 0/4] OMAPDSS: Add support for panel ls037v7dw01
* Tomi Valkeinen tomi.valkei...@ti.com [140509 02:34]: On 05/05/14 21:41, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [140429 16:53]: Hi all, Here are few patches to add devicetree support for panel ls037v7dw01 that's found on many omap3 boards. They seem to be often mis-configured as various panel dpi entries, but really should be move to use panel ls037v7dw01 instead. This panel is found at least on the omap3 sdp, ldp, omap3 evm and few other development boards. Tomi, assuming no more comments, do you want to pick up the first three patches of this series? I can queue the .dts changes or you can also set up a separate .dts changes branch for DSS that I can merge in too. If it's all the same to you, I'd like to collect all display related arch/arm/ patches into my tree, and I'll send you a merge request when it's stable. I already have OMAP5 and AM43xx stuff there. Yes that works well for me. 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: dts: am335x-evm: fix comments for lcd pins
Wolfram,
Wolfram Sang w...@the-dreams.de wrote on Fri [2014-May-09 17:15:50 +0200]:
From: Wolfram Sang w...@sang-engineering.com
In the comments, LCD pins 16-23 were numbered in the wrong order.
Fix this and use proper pinmux constants for all entries while we are
Looks like you are absolutely correct - I just confirmed this from both
the AM335x-EVM schematic and the AM335x pinmux utility.
The same mistake is also in my EVMSK LCD enabling patch that is floating
around on this list at the moment. I will fix that and resend it.
BeagleBone Black only uses the first 16 LCD pins so the dts for that is
correct.
Thanks for finding and fixing it.
Darren
Signed-off-by: Wolfram Sang w...@sang-engineering.com
Cc: Benoit Parrot bpar...@ti.com
---
arch/arm/boot/dts/am335x-evm.dts | 56
1 file changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 6028217ace0f..1b642f1cd469 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -268,34 +268,34 @@
lcd_pins_s0: lcd_pins_s0 {
pinctrl-single,pins =
- 0x20 0x01 /* gpmc_ad8.lcd_data16, OUTPUT | MODE1
*/
- 0x24 0x01 /* gpmc_ad9.lcd_data17, OUTPUT | MODE1
*/
- 0x28 0x01 /* gpmc_ad10.lcd_data18, OUTPUT | MODE1
*/
- 0x2c 0x01 /* gpmc_ad11.lcd_data19, OUTPUT | MODE1
*/
- 0x30 0x01 /* gpmc_ad12.lcd_data20, OUTPUT | MODE1
*/
- 0x34 0x01 /* gpmc_ad13.lcd_data21, OUTPUT | MODE1
*/
- 0x38 0x01 /* gpmc_ad14.lcd_data22, OUTPUT | MODE1
*/
- 0x3c 0x01 /* gpmc_ad15.lcd_data23, OUTPUT | MODE1
*/
- 0xa0 0x00 /* lcd_data0.lcd_data0, OUTPUT | MODE0
*/
- 0xa4 0x00 /* lcd_data1.lcd_data1, OUTPUT | MODE0
*/
- 0xa8 0x00 /* lcd_data2.lcd_data2, OUTPUT | MODE0
*/
- 0xac 0x00 /* lcd_data3.lcd_data3, OUTPUT | MODE0
*/
- 0xb0 0x00 /* lcd_data4.lcd_data4, OUTPUT | MODE0
*/
- 0xb4 0x00 /* lcd_data5.lcd_data5, OUTPUT | MODE0
*/
- 0xb8 0x00 /* lcd_data6.lcd_data6, OUTPUT | MODE0
*/
- 0xbc 0x00 /* lcd_data7.lcd_data7, OUTPUT | MODE0
*/
- 0xc0 0x00 /* lcd_data8.lcd_data8, OUTPUT | MODE0
*/
- 0xc4 0x00 /* lcd_data9.lcd_data9, OUTPUT | MODE0
*/
- 0xc8 0x00 /* lcd_data10.lcd_data10, OUTPUT |
MODE0 */
- 0xcc 0x00 /* lcd_data11.lcd_data11, OUTPUT |
MODE0 */
- 0xd0 0x00 /* lcd_data12.lcd_data12, OUTPUT |
MODE0 */
- 0xd4 0x00 /* lcd_data13.lcd_data13, OUTPUT |
MODE0 */
- 0xd8 0x00 /* lcd_data14.lcd_data14, OUTPUT |
MODE0 */
- 0xdc 0x00 /* lcd_data15.lcd_data15, OUTPUT |
MODE0 */
- 0xe0 0x00 /* lcd_vsync.lcd_vsync, OUTPUT | MODE0
*/
- 0xe4 0x00 /* lcd_hsync.lcd_hsync, OUTPUT | MODE0
*/
- 0xe8 0x00 /* lcd_pclk.lcd_pclk, OUTPUT | MODE0 */
- 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en,
OUTPUT | MODE0 */
+ 0x20 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad8.lcd_data23 */
+ 0x24 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad9.lcd_data22 */
+ 0x28 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad10.lcd_data21 */
+ 0x2c (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad11.lcd_data20 */
+ 0x30 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad12.lcd_data19 */
+ 0x34 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad13.lcd_data18 */
+ 0x38 (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad14.lcd_data17 */
+ 0x3c (PIN_OUTPUT | MUX_MODE1) /*
gpmc_ad15.lcd_data16 */
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data0.lcd_data0 */
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data1.lcd_data1 */
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data2.lcd_data2 */
+ 0xac (PIN_OUTPUT | MUX_MODE0) /*
lcd_data3.lcd_data3 */
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data4.lcd_data4 */
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data5.lcd_data5 */
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data6.lcd_data6 */
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /*
Re: [PATCH] ARM: dts: Correct offset in OMAP4_WKUP_IOPAD macro
* Joachim Eastwood manab...@gmail.com [140509 05:58]: On 6 May 2014 02:12, Tony Lindgren t...@atomide.com wrote: OK sorry just noticed you're using it already while was about to apply your patches. Care to update that series again to not use the macro, or by adding the offsets? hm, I'd rather add offsets than remove the macro's now. How about we introduce a mask parameter in to the OMAP_IOPAD_OFFSET macro? Something like this: #define OMAP_IOPAD_OFFSET(pa, offset, mask) (((pa) mask) - ((offset) mask)) #define OMAP4_CORE_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0x0040, 0xfff) (val) #define OMAP4_WKUP_IOPAD(pa, val) OMAP_IOPAD_OFFSET((pa), 0xe040, 0xfff) (val) Of course we need to fix the other users as well. I was thinking that too initially, but then we would have macros that behave in a different way: 1. Calculate the iopad offset from the iopad register area start based on the iopad physical address 2. Calculate the iopad offset from the iopad register area start based on the iopadd offset from the driver base address One other possibility is to use my original patch in this mail or just create a OMAP4_IOPAD with offset 0x040 which will on OMAP4 work for both core and wkup. That also makes the macro behave in a different way depending on the SoC which is not nice. What do you think? I think it's best to add some new macros to avoid confusion. 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: dts: am335x-evm: fix comments for lcd pins
The same mistake is also in my EVMSK LCD enabling patch that is floating around on this list at the moment. I will fix that and resend it. BeagleBone Black only uses the first 16 LCD pins so the dts for that is correct. Well, even in the TI-based-3.2-kernel I originally got with the custom hardware, this mistake was present in mach-omap2/mux33xx.c. No wonder it spread from there :) Thanks for finding and fixing it. Very welcome! signature.asc Description: Digital signature
Re: [PATCH] ARM: dts: am335x-bone-common: Add i2c2 definition
On Fri, May 9, 2014 at 5:57 AM, Nishanth Menon n...@ti.com wrote:
On Fri 09 May 2014 12:56:23 AM CDT, Matt Ranostay wrote:
Add missing i2c2 bus define to access various cape and
prototype/breakout board devices.
Signed-off-by: Matt Ranostay mranos...@gmail.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2e7d932..2aedfee 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -84,6 +84,13 @@
;
};
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins =
+ 0x178 (PIN_INPUT_PULLUP | MUX_MODE3)/*
i2c2_sda.uart1_ctsn */
+ 0x17c (PIN_INPUT_PULLUP | MUX_MODE3)/*
i2c2_scl.uart1_rtsn */
I dont understand the comment - i2c2_sda is being muxed to uart1_cstsn?
Good catch I mixed up the ordering of the comment.
+ ;
+ };
+
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins =
0x170 (PIN_INPUT_PULLUP | MUX_MODE0)/*
uart0_rxd.uart0_rxd */
@@ -222,6 +229,15 @@
};
+
+i2c2 {
+ pinctrl-names = default;
+ pinctrl-0 = i2c2_pins;
+
+ status = okay;
+ clock-frequency = 40;
How did we decide on 400KHz - do all all i2c2 devices on ALL capes
work in full speed? OR should we consider a conservative 100KHz?
Probably a better plan.
Will submit v2 this weekend.
+};
+
/include/ tps65217.dtsi
tps {
--
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] arm/dts: am335x-evmsk enable display and lcd panel support
Darren Etheridge detheri...@ti.com wrote on Fri [2014-May-09 09:47:49 -0500]: Tomi Valkeinen tomi.valkei...@ti.com wrote on Fri [2014-May-09 14:29:02 +0300]: On 06/05/14 19:10, Tony Lindgren wrote: * Darren Etheridge detheri...@ti.com [140422 13:39]: Add the necessary nodes to enable the LCD controller and the LCD panel that is attached to the Texas Instruments AM335x EVMSK platform. Also setup the necessary pin mux within the DT file to drive the LCD connector and add the correct pinmux settings for the lcd pins to be configured to when the SoC goes into sleep state for the minimum power consumption. For the sleep mode LCD pin settings, MUX_MODE7 is chosen as this corresponds to switching the pins into input GPIO's with an internal pulldown. Which has been determined to offer the lowest power solution vs leaving the pins configured in LCD mode. Probably best that Tomi queues all the panel .dts changes into a separate immutable branch that I can merge too. This is not for OMAP DSS, but for the LCDC used in beaglebone, so there are no dependencies to any of my work. Benoit had always queued these LCDC dts patches in the past. This is exactly the same as what had been done for AM335x-EVM and AM335x-BeagleBone both of which are already in the mainline kernel. I had just missed the EVMSK previously. Darren There is a labeling mistake in this patch with the comments for LCD pins 16 through 23. I will correct it and send a V2. -- 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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/6] mmc: omap_hsmmc: use devm_request_threaded_irq
With devm_request_threaded_irq conversion free_irq can be removed
in clean up path
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ef7e48a..6179fe3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2043,9 +2043,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
/* Request IRQ for card detect */
if ((mmc_slot(host).card_detect_irq)) {
- ret = request_threaded_irq(mmc_slot(host).card_detect_irq,
- NULL,
- omap_hsmmc_detect,
+ ret = devm_request_threaded_irq(pdev-dev,
+ mmc_slot(host).card_detect_irq,
+ NULL, omap_hsmmc_detect,
IRQF_TRIGGER_RISING |
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
mmc_hostname(mmc), host);
if (ret) {
@@ -2088,7 +2088,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
err_slot_name:
mmc_remove_host(mmc);
- free_irq(mmc_slot(host).card_detect_irq, host);
err_irq_cd:
if (host-use_reg)
omap_hsmmc_reg_put(host);
@@ -2127,8 +2126,6 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
omap_hsmmc_reg_put(host);
if (host-pdata-cleanup)
host-pdata-cleanup(pdev-dev);
- if (mmc_slot(host).card_detect_irq)
- free_irq(mmc_slot(host).card_detect_irq, host);
if (host-tx_chan)
dma_release_channel(host-tx_chan);
--
1.7.5.4
--
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 5/6] mmc: omap_hsmmc: fix cmd23 multiblock read/write
Check for set block count command fails always since host-cmd is
set to NULL in the same function incorrectly. Correct host-cmd usage properly.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 140425c..cba71d6 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -920,16 +920,17 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, struct
mmc_data *data)
static void
omap_hsmmc_cmd_done(struct omap_hsmmc_host *host, struct mmc_command *cmd)
{
- host-cmd = NULL;
-
if (host-mrq-sbc (host-cmd == host-mrq-sbc)
!host-mrq-sbc-error !(host-flags AUTO_CMD23)) {
+ host-cmd = NULL;
omap_hsmmc_start_dma_transfer(host);
omap_hsmmc_start_command(host, host-mrq-cmd,
host-mrq-data);
return;
}
+ host-cmd = NULL;
+
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136) {
/* response type 2 */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/6] mmc: omap_hsmmc: use devm_clk_get
With devm_clk_get conversion clk_put can be removed in clean up path
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b4de63b..b8ae7ee 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1922,7 +1922,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
spin_lock_init(host-irq_lock);
- host-fclk = clk_get(pdev-dev, fck);
+ host-fclk = devm_clk_get(pdev-dev, fck);
if (IS_ERR(host-fclk)) {
ret = PTR_ERR(host-fclk);
host-fclk = NULL;
@@ -1941,7 +1941,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_context_save(host);
- host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
+ host-dbclk = devm_clk_get(pdev-dev, mmchsdb_fck);
/*
* MMC can still work without debounce clock.
*/
@@ -1949,7 +1949,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host-dbclk = NULL;
} else if (clk_prepare_enable(host-dbclk) != 0) {
dev_warn(mmc_dev(host-mmc), Failed to enable debounce clk\n);
- clk_put(host-dbclk);
host-dbclk = NULL;
}
@@ -2105,11 +2104,8 @@ err_irq:
dma_release_channel(host-rx_chan);
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-dbclk) {
+ if (host-dbclk)
clk_disable_unprepare(host-dbclk);
- clk_put(host-dbclk);
- }
err1:
iounmap(host-base);
mmc_free_host(mmc);
@@ -2144,11 +2140,8 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-dbclk) {
+ if (host-dbclk)
clk_disable_unprepare(host-dbclk);
- clk_put(host-dbclk);
- }
omap_hsmmc_gpio_free(host-pdata);
iounmap(host-base);
--
1.7.5.4
--
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 4/6] mmc: omap_hsmmc: use devm_ioremap_resource
With devm_ioremap_resource conversion release_mem_region, iounmap can be
removed in clean up path
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 19 +--
1 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6179fe3..140425c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1851,6 +1851,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
unsigned tx_req, rx_req;
struct pinctrl *pinctrl;
const struct omap_mmc_of_data *data;
+ void __iomem *base;
match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev);
if (match) {
@@ -1881,9 +1882,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
if (res == NULL || irq 0)
return -ENXIO;
- res = request_mem_region(res-start, resource_size(res), pdev-name);
- if (res == NULL)
- return -EBUSY;
+ base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(base))
+ return PTR_ERR(base);
ret = omap_hsmmc_gpio_init(pdata);
if (ret)
@@ -1904,7 +1905,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
host-irq = irq;
host-slot_id = 0;
host-mapbase = res-start + pdata-reg_offset;
- host-base = ioremap(host-mapbase, SZ_4K);
+ host-base = base + pdata-reg_offset;
host-power_mode = MMC_POWER_OFF;
host-next_data.cookie = 1;
host-pbias_enabled = 0;
@@ -2104,21 +2105,16 @@ err_irq:
if (host-dbclk)
clk_disable_unprepare(host-dbclk);
err1:
- iounmap(host-base);
mmc_free_host(mmc);
err_alloc:
omap_hsmmc_gpio_free(pdata);
err:
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res)
- release_mem_region(res-start, resource_size(res));
return ret;
}
static int omap_hsmmc_remove(struct platform_device *pdev)
{
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
- struct resource *res;
pm_runtime_get_sync(host-dev);
mmc_remove_host(host-mmc);
@@ -2138,13 +2134,8 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
clk_disable_unprepare(host-dbclk);
omap_hsmmc_gpio_free(host-pdata);
- iounmap(host-base);
mmc_free_host(host-mmc);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res)
- release_mem_region(res-start, resource_size(res));
-
return 0;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/6] mmc: omap_hsmmc: convert to use devm_* and fixes
v2: use devm_ioremap_resource add cmd23 multiblock read/write fix Balaji T K (6): mmc: omap_hsmmc: use devm_clk_get mmc: omap_hsmmc: use devm_request_irq mmc: omap_hsmmc: use devm_request_threaded_irq mmc: omap_hsmmc: use devm_ioremap_resource mmc: omap_hsmmc: fix cmd23 multiblock read/write mmc: omap_hsmmc: split omap-dma header file drivers/mmc/host/omap_hsmmc.c | 57 --- include/linux/omap-dma.h | 19 + include/linux/omap-dmaengine.h | 21 ++ 3 files changed, 40 insertions(+), 57 deletions(-) create mode 100644 include/linux/omap-dmaengine.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/6] mmc: omap_hsmmc: use devm_request_irq
With devm_request_irq conversion free_irq can be removed in clean up path
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b8ae7ee..ef7e48a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2017,7 +2017,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
}
/* Request IRQ for MMC operations */
- ret = request_irq(host-irq, omap_hsmmc_irq, 0,
+ ret = devm_request_irq(pdev-dev, host-irq, omap_hsmmc_irq, 0,
mmc_hostname(mmc), host);
if (ret) {
dev_err(mmc_dev(host-mmc), Unable to grab HSMMC IRQ\n);
@@ -2028,7 +2028,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
if (pdata-init(pdev-dev) != 0) {
dev_err(mmc_dev(host-mmc),
Unable to configure MMC IRQs\n);
- goto err_irq_cd_init;
+ goto err_irq;
}
}
@@ -2095,8 +2095,6 @@ err_irq_cd:
err_reg:
if (host-pdata-cleanup)
host-pdata-cleanup(pdev-dev);
-err_irq_cd_init:
- free_irq(host-irq, host);
err_irq:
if (host-tx_chan)
dma_release_channel(host-tx_chan);
@@ -2129,7 +2127,6 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
omap_hsmmc_reg_put(host);
if (host-pdata-cleanup)
host-pdata-cleanup(pdev-dev);
- free_irq(host-irq, host);
if (mmc_slot(host).card_detect_irq)
free_irq(mmc_slot(host).card_detect_irq, host);
--
1.7.5.4
--
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 6/6] mmc: omap_hsmmc: split omap-dma header file
moving dmaengine consumer specific function to omap-dmaengine.h
to Resolve build failure seen with sh-allmodconfig:
include/linux/omap-dma.h:171:8: error: expected identifier before numeric
constant
make[4]: *** [drivers/mmc/host/omap_hsmmc.o] Error 1
Cc: Russell King - ARM Linux li...@arm.linux.org.uk
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
include/linux/omap-dma.h | 19 +--
include/linux/omap-dmaengine.h | 21 +
3 files changed, 23 insertions(+), 19 deletions(-)
create mode 100644 include/linux/omap-dmaengine.h
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index cba71d6..6b7b755 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -31,7 +31,7 @@
#include linux/of.h
#include linux/of_gpio.h
#include linux/of_device.h
-#include linux/omap-dma.h
+#include linux/omap-dmaengine.h
#include linux/mmc/host.h
#include linux/mmc/core.h
#include linux/mmc/mmc.h
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 41a13e7..999f52d 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -1,23 +1,6 @@
-/*
- * OMAP DMA Engine support
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
#ifndef __LINUX_OMAP_DMA_H
#define __LINUX_OMAP_DMA_H
-
-struct dma_chan;
-
-#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
-bool omap_dma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
-{
- return false;
-}
-#endif
+#include linux/omap-dmaengine.h
/*
* Legacy OMAP DMA handling defines and functions
diff --git a/include/linux/omap-dmaengine.h b/include/linux/omap-dmaengine.h
new file mode 100644
index 000..2b0b6aa
--- /dev/null
+++ b/include/linux/omap-dmaengine.h
@@ -0,0 +1,21 @@
+/*
+ * OMAP DMA Engine support
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_OMAP_DMAENGINE_H
+#define __LINUX_OMAP_DMAENGINE_H
+
+struct dma_chan;
+
+#if defined(CONFIG_DMA_OMAP) || defined(CONFIG_DMA_OMAP_MODULE)
+bool omap_dma_filter_fn(struct dma_chan *, void *);
+#else
+static inline bool omap_dma_filter_fn(struct dma_chan *c, void *d)
+{
+ return false;
+}
+#endif
+#endif /* __LINUX_OMAP_DMAENGINE_H */
--
1.7.5.4
--
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 v11 2/7] mmc: omap_hsmmc: Enable SDIO interrupt
On Friday 09 May 2014 04:50 AM, Andreas Fenkart wrote:
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
david.vra...@csr.com, Steve Sakoman st...@sakoman.com
For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.
To use it, you need to specify the wake-irq using the
interrupts-extended property.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Cc: Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
Hi Andreas,
Thanks for the new patch series.
Minor nit below,
other than that
Acked-by: Balaji T K balaj...@ti.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5042a15..f43a69e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -133,6 +135,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN(1 4)
#define BRR_EN(1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN(1 15)
#define CTO_EN(1 16)
#define CCRC_EN (1 17)
@@ -167,7 +170,6 @@ static void apply_clk_hack(struct device *dev)
#define VDD_3V0 300 /* 30 uV */
#define VDD_165_195 (ffs(MMC_VDD_165_195) - 1)
-#define AUTO_CMD23 (1 1) /* Auto CMD23 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -221,6 +223,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int wake_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -233,6 +236,9 @@ struct omap_hsmmc_host {
int req_in_progress;
unsigned long clk_rate;
unsigned intflags;
+#define AUTO_CMD23 (1 0)/* Auto CMD23 support */
+#define HSMMC_SDIO_IRQ_ENABLED (1 1)/* SDIO irq enabled */
+#define HSMMC_WAKE_IRQ_ENABLED (1 2)
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -537,27 +543,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal MMC core */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base,
Re: [PATCH v11 4/7] mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
On Friday 09 May 2014 04:50 AM, Andreas Fenkart wrote:
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Looks good to me
Acked-by: Balaji T K balaj...@ti.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f76462d..14857d7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -83,6 +83,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA 0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL 0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT 0x0130
@@ -1854,14 +1855,29 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ bool suspended;
- seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
- mmc-index, host-context_loss);
+ seq_printf(s, mmc%d:\n, mmc-index);
+ seq_printf(s, sdio irq mode\t%s\n,
+ (mmc-caps MMC_CAP_SDIO_IRQ) ? interrupt : polling);
- pm_runtime_get_sync(host-dev);
+ if (mmc-caps MMC_CAP_SDIO_IRQ) {
+ seq_printf(s, sdio irq \t%s\n,
+ (host-flags HSMMC_SDIO_IRQ_ENABLED) ? enabled
+ : disabled);
+ }
+
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ seq_printf(s, runtime state\t%s\n, (suspended ? idle : active));
+ seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
+
+ pm_runtime_get_sync(host-dev);
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
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 v11 7/7] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x
On Friday 09 May 2014 04:50 AM, Andreas Fenkart wrote:
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren. Code contributions from
Tony Lindgren and Balaji T K balaj...@ti.com
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Signed-off-by: Tony Lindgren t...@atomide.com
Conflicts:
drivers/mmc/host/omap_hsmmc.c
Remove above 2 lines
Acked-by: Balaji T K balaj...@ti.com
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ce80561..946bc5f 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -56,3 +56,56 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even register reads
+will fail. A small logic in the host will request fclk restore, when an
+external event is detected. Once the clock is restored, the host detects the
+event normally. Since am33xx doesn't have this line it never wakes from
+suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon suspend. To make
+this work, we need to set the named pinctrl states default and idle.
+Prepare idle to remux dat1 as a gpio, and default to remux it back as sdio
+dat1. The MMC driver will then toggle between idle and default state during
+runtime.
+
+In summary:
+1. select matching 'compatible' section, see example below.
+2. specify pinctrl states default and idle, sleep is optional.
+3. specify the gpio irq used for detecting sdio irq in suspend
+
+If configuration is incomplete, a warning message is emitted falling back to
+polling. Also check the sdio irq mode in /sys/kernel/debug/mmc0/regs. Mind
+not every application needs SDIO irq, e.g. MMC cards.
+
+ mmc1: mmc@48060100 {
+ compatible = ti,am33xx-hsmmc;
+ ...
+ pinctrl-names = default, idle, sleep
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_idle;
+ pinctrl-2 = mmc1_sleep;
+ ...
+ interrupts-extended = intc 64 gpio2 28 0;
+ };
+
+ mmc1_idle : pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* GPIO2_28 */
+ ;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5a321f98..497b2fc 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1782,15 +1782,25 @@ static int omap_hsmmc_configure_wake_irq(struct
omap_hsmmc_host *host)
* and need to remux SDIO DAT1 to GPIO for wake-up from idle.
*/
if (host-pdata-controller_flags OMAP_HSMMC_SWAKEUP_MISSING) {
- ret = -ENODEV;
- devm_free_irq(host-dev, host-wake_irq, host);
- goto err;
+ if (IS_ERR(host-dev-pins-default_state)) {
+ dev_info(host-dev, missing default pinctrl state\n);
+ ret = -EINVAL;
+ goto err_free_irq;
+ }
+
+ if (IS_ERR(host-dev-pins-idle_state)) {
+ dev_info(host-dev, missing idle pinctrl state\n);
+ ret = -EINVAL;
+ goto err_free_irq;
+ }
}
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) | IWE);
return 0;
+err_free_irq:
+ devm_free_irq(host-dev, host-wake_irq, host);
err:
dev_warn(host-dev, no SDIO IRQ support, falling back to polling\n);
host-wake_irq = 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: [PATCH v11 6/7] mmc: omap_hsmmc: switch default/idle pinctrl states in runtime hooks
On Friday 09 May 2014 04:50 AM, Andreas Fenkart wrote:
These are predefined states of the driver model. When not present,
as if not set in the device tree, they become no-ops.
Explicitly selecting the default state is not needed since the
device core layer sets pin mux to default state before probe.
This is not the simplest implementation, on AM335x at least, we could
switch to idle at any point in the suspend hook, only the default state
needs to be set before writing to the irq registers or an IRQ might get
lost.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 47a5982..5a321f98 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2032,7 +2032,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
- struct pinctrl *pinctrl;
const struct omap_mmc_of_data *data;
apply_clk_hack(pdev-dev);
Looks like this patches is not based on mmc-next[1]
Can you please rebase to mmc-next
[1]
http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc.git/log/?id=refs/heads/mmc-next
Other than that:
Acked-by: Balaji T K balaj...@ti.com
@@ -2258,11 +2257,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_disable_irq(host);
- pinctrl = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(pinctrl))
- dev_warn(pdev-dev,
- pins are not configured from the driver\n);
-
/*
* For now, only support SDIO interrupt if we have a separate
* wake-up interrupt configured from device tree. This is because
@@ -2486,10 +2480,15 @@ static int omap_hsmmc_runtime_suspend(struct device
*dev)
goto abort;
}
+ pinctrl_pm_select_idle_state(dev);
+
WARN_ON(host-flags HSMMC_WAKE_IRQ_ENABLED);
enable_irq(host-wake_irq);
host-flags |= HSMMC_WAKE_IRQ_ENABLED;
+ } else {
+ pinctrl_pm_select_idle_state(dev);
}
+
abort:
spin_unlock_irqrestore(host-irq_lock, flags);
return ret;
@@ -2513,9 +2512,14 @@ static int omap_hsmmc_runtime_resume(struct device *dev)
host-flags = ~HSMMC_WAKE_IRQ_ENABLED;
}
+ pinctrl_pm_select_default_state(host-dev);
+
+ /* irq lost, if pinmux incorrect */
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+ } else {
+ pinctrl_pm_select_default_state(host-dev);
}
spin_unlock_irqrestore(host-irq_lock, flags);
return 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: [PATCH v11 5/7] mmc: omap_hsmmc: abort runtime suspend if pending sdio irq detected
On Friday 09 May 2014 04:50 AM, Andreas Fenkart wrote:
On multicores, an sdio irq handler could be running in parallel to
runtime suspend. In the worst case it could be waiting for the spinlock
held by the runtime suspend. When runtime suspend is complete and the
functional clock (fclk) turned off, the irq handler will continue and
cause a SIGBUS on the first register access.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
Acked-by: Balaji T K balaj...@ti.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 14857d7..47a5982 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -134,6 +134,9 @@ static void apply_clk_hack(struct device *dev)
#define SRD (1 26)
#define SOFTRESET (1 1)
+/* PSTATE */
+#define DLEV_DAT(x)(1 (20 + (x)))
+
/* Interrupt masks for IE and ISE register */
#define CC_EN (1 0)
#define TC_EN (1 1)
@@ -2455,6 +2458,7 @@ static int omap_hsmmc_runtime_suspend(struct device *dev)
{
struct omap_hsmmc_host *host;
unsigned long flags;
+ int ret = 0;
host = platform_get_drvdata(to_platform_device(dev));
omap_hsmmc_context_save(host);
@@ -2466,14 +2470,29 @@ static int omap_hsmmc_runtime_suspend(struct device
*dev)
/* disable sdio irq handling to prevent race */
OMAP_HSMMC_WRITE(host-base, ISE, 0);
OMAP_HSMMC_WRITE(host-base, IE, 0);
- OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+
+ if (!(OMAP_HSMMC_READ(host-base, PSTATE) DLEV_DAT(1))) {
+ /*
+* dat1 line low, pending sdio irq
+* race condition: possible irq handler running on
+* multi-core, abort
+*/
+ dev_dbg(dev, pending sdio irq, abort suspend\n);
+ OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ OMAP_HSMMC_WRITE(host-base, ISE, CIRQ_EN);
+ OMAP_HSMMC_WRITE(host-base, IE, CIRQ_EN);
+ pm_runtime_mark_last_busy(dev);
+ ret = -EBUSY;
+ goto abort;
+ }
WARN_ON(host-flags HSMMC_WAKE_IRQ_ENABLED);
enable_irq(host-wake_irq);
host-flags |= HSMMC_WAKE_IRQ_ENABLED;
}
+abort:
spin_unlock_irqrestore(host-irq_lock, flags);
- return 0;
+ return ret;
}
static int omap_hsmmc_runtime_resume(struct device *dev)
--
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: dts: am335x-evm: fix comments for lcd pins
Darren Etheridge detheri...@ti.com wrote on Fri [2014-May-09 10:59:30 -0500]: Wolfram, Wolfram Sang w...@the-dreams.de wrote on Fri [2014-May-09 17:15:50 +0200]: From: Wolfram Sang w...@sang-engineering.com In the comments, LCD pins 16-23 were numbered in the wrong order. Fix this and use proper pinmux constants for all entries while we are Looks like you are absolutely correct - I just confirmed this from both the AM335x-EVM schematic and the AM335x pinmux utility. The same mistake is also in my EVMSK LCD enabling patch that is floating around on this list at the moment. I will fix that and resend it. BeagleBone Black only uses the first 16 LCD pins so the dts for that is correct. Thanks for finding and fixing it. In the process of fixing up my EVMSK patch I applied this patch and tested it on a 3.15-rc4 kernel running on an AM335x-EVM. Worked great - so your pinmux constant conversion appears to be correct. Tested-by: Darren Etheridge detheri...@ti.com -- 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
