Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
Quoting Tomi Valkeinen (2014-05-12 05:13:51) On 12/05/14 15:02, Tero Kristo wrote: On 05/08/2014 12:06 PM, Tomi Valkeinen wrote: The current DPLL code does not try to round the clock rate, and instead returns an error if the requested clock rate cannot be produced exactly by the DPLL. It could be argued that this is a bug, but as the current drivers may depend on that behavior, a new flag 'ti,round-rate' is added which enables clock rate rounding. Someone could probably argue that this flag is not a hardware feature, I fully agree. but instead is used to describe linux-kernel behavior, and would probably be frowned upon by the DT enthusiasts. Othen than that, I like this approach better than a global setting, but would like second opinions here. I think the dpll code should always do rounding. That's what round_rate() is supposed to do, afaik. The current behavior of not rounding and returning an error is a bug in my opinion. From include/linux/clk.h: /** * clk_round_rate - adjust a rate to the exact rate a clock can provide * @clk: clock source * @rate: desired clock rate in Hz * * Returns rounded clock rate in Hz, or negative errno. */ long clk_round_rate(struct clk *clk, unsigned long rate); Definitely not rounding the rate is a bug, with respect to the API definition. Has anyone tried making the new flag as the default behavior and seeing if anything breaks? For those users of the omapconf tool I enjoy doing something like the following: boot current, buggy behavior omapconf dump prcm old boot with Tomi's flag enabled for all DPLLs by default omapconf dump prcm new diff -u old new This should reveal any deltas, assuming the board boots and doesn't let magic smoke out. Regards, Mike So, if you ask me, the whole flag is just for the purpose of keeping the current drivers working, which could depend on the broken behavior. But I think we cannot have such drivers (functional, at least) in any case, as the clk-divider driver is broken and doesn't handle the errors the dpll code currently returns for non-exact rates. 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: [RFC PATCH] ARM: dts: am33xx: Re-arrange the USB dt to reflect the h/w configuration
Hi Tony,
On 5/15/2014 3:20 AM, Tony Lindgren wrote:
* George Cherian george.cher...@ti.com [140508 23:34]:
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
}
}
Is this just a cosmetic change or is this trying to workaround
some edma related init order issue?
Please ignore this patch. Was trying to workaround some dma and phy
related issues.
The same got fixed with following
http://www.spinics.net/lists/linux-usb/msg107244.html
Regards,
Tony
--
-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 v3 0/5] Add support for SW babble Control
Hi Bin,
On 5/14/2014 10:13 PM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without an
IP
reset .
2) Babble condition - which could be recovered from only by doing an IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP core.
How do you test babble errors, is there any way to force them to happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.
But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.
Oops I missed to mention the same.
Please try on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
Thanks,
-Bin.
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.
Thanks,
-Bin.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-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
--
-George
--
-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
hang-ups, using SanDisk Extreme Pro microSD cards
Dear All, I am using a ISEE Igepv2 CPU board, booting from microSD card. I am using SanDisk Extreme Pro 8GByte cards. I experience occasional hang-ups of the Linux system in different severity: 1.) System seems to hang for some seconds, but afterwards continues work with no kernel messages in this case 2.) kernel is putting out message: [ 4211.686096] mmcblk0: error -110 sending read/write command, response 0x900, card status 0xe00 [ 4211.701538] mmcblk0: error -110 transferring data, sector 674693, nr 42, card status 0xc00 Afterwards the Linux system is completely dead - no SSH, no ping, nothing. The problem occurs quite often - every 4rd to 5th reboot after a few minutes working time. I have used the ISEE Igepv2 kernel 2.6.37-8 and Igep X-Loader 2.6.0-1 in this case with igep00x0-defconfig. Linux system is compiled, using the Pengutronix PTXDist 2011-11-0 cross compile environment I tried afterwards on same CPU board with Transcend Premium 8GByte cards with no problems. I tried with mainline kernel 3.15-rc4 and u-boot-2014-04 afterwards. Here I do not get the above messages, but still with some SanDisk cards I get a complete system hang-up. Same, with Transcend cards, or even some other SanDisk cards I do not have problems. The Linux images are duplicated using a script with parted, mkfs and tar to copy the images. Does anybody else already had such problems? best regards, Martin Wilde-- 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 3/5] dt/bindings: ti,edma: Remove redundant properties from documentation
On Tuesday 13 May 2014 13:30:30 Peter Ujfalusi wrote: From CCCFG register of eDMA3 we can get all the needed information for the driver about the IP: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE The ti,edma-regions; ti,edma-slots and dma-channels in DT are redundant since the very same information can be obtained from the HW. The mentioned properties can be removed from the binding document. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com I wonder if we should keep them listed as optional properties so you can have a dtb file that still works with older kernels which need them. What you do is an incompatible change to the binding, which we shouldn't do lightly. Any new dts files don't need this information of course, but as a general rule, I'd rather keep things like this around unless we already have to enforce an ABI break that is well documented. 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] OMAPDSS: move 'compatible' converter to omapdss driver
Move the panel/encoder driver compatible-string converter from
arch/arm/mach-omap2/display.c to omapdss driver. That is a more logical
place for it, as it's really an omapdss internal hack.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 56 ---
drivers/video/fbdev/omap2/Makefile| 2 +-
drivers/video/fbdev/omap2/dss/Kconfig | 4 +
drivers/video/fbdev/omap2/dss/Makefile| 1 +
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 112 ++
5 files changed, 118 insertions(+), 57 deletions(-)
create mode 100644 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 16d33d831287..519a20fc0432 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -555,65 +555,9 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
-/* list of 'compatible' nodes to convert to omapdss specific */
-static const char * const dss_compat_conv_list[] __initconst = {
- composite-connector,
- dvi-connector,
- hdmi-connector,
- panel-dpi,
- panel-dsi-cm,
- sony,acx565akm,
- svideo-connector,
- ti,tfp410,
- ti,tpd12s015,
-};
-
-/* prepend compatible string with omapdss, */
-static __init void omapdss_omapify_node(struct device_node *node,
- const char *compat)
-{
- char *new_compat;
- struct property *prop;
-
- new_compat = kasprintf(GFP_KERNEL, omapdss,%s, compat);
-
- prop = kzalloc(sizeof(*prop), GFP_KERNEL);
-
- if (!prop) {
- pr_err(omapdss_omapify_node: kzalloc failed\n);
- return;
- }
-
- prop-name = compatible;
- prop-value = new_compat;
- prop-length = strlen(new_compat) + 1;
-
- of_update_property(node, prop);
-}
-
-/*
- * As omapdss panel drivers are omapdss specific, but we want to define the
- * DT-data in generic manner, we convert the compatible strings of the panel
- * nodes from panel-foo to omapdss,panel-foo. This way we can have both
- * correct DT data and omapdss specific drivers.
- *
- * When we get generic panel drivers to the kernel, this will be removed.
- */
void __init omapdss_early_init_of(void)
{
- int i;
-
- for (i = 0; i ARRAY_SIZE(dss_compat_conv_list); ++i) {
- const char *compat = dss_compat_conv_list[i];
- struct device_node *node = NULL;
-
- while ((node = of_find_compatible_node(node, NULL, compat))) {
- if (!of_device_is_available(node))
- continue;
- omapdss_omapify_node(node, compat);
- }
- }
}
struct device_node * __init omapdss_find_dss_of_node(void)
diff --git a/drivers/video/fbdev/omap2/Makefile
b/drivers/video/fbdev/omap2/Makefile
index bf8127df8c71..f8745ec369cc 100644
--- a/drivers/video/fbdev/omap2/Makefile
+++ b/drivers/video/fbdev/omap2/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
-obj-$(CONFIG_OMAP2_DSS) += dss/
+obj-y += dss/
obj-y += displays-new/
obj-$(CONFIG_FB_OMAP2) += omapfb/
diff --git a/drivers/video/fbdev/omap2/dss/Kconfig
b/drivers/video/fbdev/omap2/dss/Kconfig
index dde4281663b1..a28f3a39ab1b 100644
--- a/drivers/video/fbdev/omap2/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/dss/Kconfig
@@ -1,6 +1,10 @@
+config OMAP2_DSS_INIT
+ bool
+
menuconfig OMAP2_DSS
tristate OMAP2+ Display Subsystem support
select VIDEOMODE_HELPERS
+ select OMAP2_DSS_INIT
help
OMAP2+ Display Subsystem support.
diff --git a/drivers/video/fbdev/omap2/dss/Makefile
b/drivers/video/fbdev/omap2/dss/Makefile
index 8aec8bda27cc..3b79ad74f2e1 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_OMAP2_DSS_INIT) += omapdss-boot-init.o
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
new file mode 100644
index ..468f6eff370c
--- /dev/null
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2014 Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * 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
Re: [PATCH v2 3/5] dt/bindings: ti,edma: Remove redundant properties from documentation
On 05/15/2014 11:01 AM, Arnd Bergmann wrote: On Tuesday 13 May 2014 13:30:30 Peter Ujfalusi wrote: From CCCFG register of eDMA3 we can get all the needed information for the driver about the IP: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE The ti,edma-regions; ti,edma-slots and dma-channels in DT are redundant since the very same information can be obtained from the HW. The mentioned properties can be removed from the binding document. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com I wonder if we should keep them listed as optional properties so you can have a dtb file that still works with older kernels which need them. What you do is an incompatible change to the binding, which we shouldn't do lightly. Any new dts files don't need this information of course, but as a general rule, I'd rather keep things like this around unless we already have to enforce an ABI break that is well documented. We could keep them as optional, or to be precise: ignored properties since we are not going to even look at them in the future. But I do not really see the reason to do so. With this change new kernels will boot with old DTB - if it can not be changed which I have not seen yet. Sure old kernel would not boot with this change, but why would you downgrade the kernel and update the DTB on a board? Bisecting is not a good reason since the bug you might be hunting for could be in the DTS or in the kernel code so you need to update both of them to be sure you reach the commit you are looking for. -- Péter -- 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 14/05/14 00:26, Tony Lindgren wrote: + /* lcd MO */ + ddata-mo_gpio = sharp_ls_get_gpio_of(pdev-dev, 0, 1, mode); + if (PTR_ERR(ddata-mo_gpio) == -EPROBE_DEFER) + return -EPROBE_DEFER; + + if (!IS_ERR(ddata-mo_gpio)) + if (gpiod_get_raw_value_cansleep(ddata-mo_gpio)) + ddata-flags |= SHARP_LS_QVGA; Shouldn't there be an explicit flag in the DT data for this? If the panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't have MO gpio, right? So something like: mode-gpios = 0 /* high, lcd MO */ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd UD */ vga-mode; /* MO hardwired high */ Btw, the gpio.txt has each gpio inside : chipsel-gpios = gpio1 12 0, gpio1 13 0, 0, /* holes are permitted, means no GPIO 2 */ gpio2 2; Is that equivalent to having all gpios inside ? Tomi signature.asc Description: OpenPGP digital signature
Re: RCU stall on panda
On 05/13/2014 11:32 PM, Tony Lindgren wrote: * Alex Shi alex@linaro.org [140512 23:37]: On 05/13/2014 05:21 AM, Tony Lindgren wrote: * Paul E. McKenney paul...@linux.vnet.ibm.com [140505 11:11]: On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote: I keep seeing the RCU stall problem on panda board from 3.10 kernel to latest upstream kernel and google find some one report it before: https://lkml.org/lkml/2012/9/20/519 Is it the hardware issue or a real software problem? I cannot distinguish between hardware and software from the trace below, but given that you are also seeing a soft lockup, either way you do appear to have a real problem as opposed to an RCU CPU stall warning false positive. Looks like you have CPU_IDLE enabled on panda. Hangs with current linux next with CPU_IDLE are currently being discussed on the linux-omap list in thread omap4-panda-es boot issues with v3.15-rc4 I've seen occasional system hangs, and I've also noticed that doing ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system producing similar errors to the below. Thanks a lot for the info. In fact, the oops keeps in upstream kernel from 3.10 to latest. Care to test if the revert of commit cb7094 Santosh posted as [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled solves the problem for you? After enable this patch, system maybe hang in idle. :( Regards, Tony -- Thanks Alex -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] ARM: edma: Get IP information from HW when booting with DT
Hi Peter,
On Tuesday 13 May 2014 04:00 PM, Peter Ujfalusi wrote:
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 128
++---
1 file changed, 79 insertions(+), 49 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index fade9ada81f8..1a98f3cd4cd9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,16 @@
#define PARM_OFFSET(param_no)(EDMA_PARM + ((param_no) 5))
#define EDMA_DCHMAP 0x0100 /* 64 registers */
-#define CHMAP_EXIST BIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x) (x 0x7) /* bits 0-2 */
+#define GET_NUM_QDMACH(x)((x 0x70) 4) /* bits 4-6 */
+#define GET_NUM_INTCH(x) ((x 0x700) 8) /* bits 8-10 */
+#define GET_NUM_PAENTRY(x) ((x 0x7000) 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x) ((x 0x7) 16) /* bits 16-18 */
+#define GET_NUM_REGN(x) ((x 0x30) 20) /* bits 20-21 */
+#define CHMAP_EXIST BIT(24)
+#define MP_EXIST BIT(25)
Of these new defines, you do not use GET_NUM_QDMACH(), GET_NUM_INTCH()
and MP_EXIST (at least in this patch). Can you please get rid of them if
not needed? May be its just me but its pretty annoying to search for a
define only to find its never used :)
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1415,6 +1424,68 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_info_from_hw(struct device *dev,
+struct edma_soc_info *pdata)
+{
+ int i;
+ u32 value, cccfg, n_tc;
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ /* Decode the eDMA3 configuration from CCCFG register */
+ cccfg = edma_read(0, EDMA_CCCFG);
You do not handle the second controller here, but its pretty straight
forward to add that by passing the controller number to this function.
I was wondering why we never read the hardware for this information
before, and strangely enough cannot find any SoC where the CCCFG
register does not publish this information correctly. I have tested on
DA850, DA830, DM365, DM355 and DM6467.
Instead of keeping this specific to OF case, the code can be simplified
much better if we read from hardware all the time. We can directly
populate the equivalent variables in the internal structure 'struct
edma' instead of populating them in 'struct edma_soc_info' and then
copying then over.
+
+ value = GET_NUM_DMACH(cccfg);
+ pdata-n_channel = BIT(value + 1);
+
+ value = GET_NUM_REGN(cccfg);
+ pdata-n_region = BIT(value);
+
+ value = GET_NUM_PAENTRY(cccfg);
+ pdata-n_slot = BIT(value + 4);
+
+ value = GET_NUM_EVQUE(cccfg);
+ n_tc = value + 1;
+
+ dev_dbg(dev, eDMA3 HW configuration (cccfg: 0x%08x):\n, cccfg);
+ dev_dbg(dev, n_channel: %u\n, pdata-n_channel);
+ dev_dbg(dev, n_region: %u\n, pdata-n_region);
+ dev_dbg(dev, n_slot: %u\n, pdata-n_slot);
+ dev_dbg(dev, n_tc: %u\n, n_tc);
+
[snip]
+ pdata-n_cc = 1;
+
+ queue_tc_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i n_tc; i++) {
+ queue_tc_map[i][0] = i;
+ queue_tc_map[i][1] = i;
+ }
+ queue_tc_map[i][0] = -1;
+ queue_tc_map[i][1] = -1;
+
+ pdata-queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i n_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata-queue_priority_mapping = queue_priority_map;
+
+ pdata-default_queue = 0;
This is part is not really setting up from hardware (rather falling back
to some sane defaults for the DT case). Could you leave them in
edma_of_parse_dt()?
@@ -1655,6 +1679,12 @@ static int edma_probe(struct platform_device *pdev)
if (IS_ERR(edmacc_regs_base[j]))
return PTR_ERR(edmacc_regs_base[j]);
+ if (node) {
+ /* Get eDMA3 configuration from IP */
+ ret = edma_setup_info_from_hw(dev, info[j]);
+ if (ret)
+ return ret;
No need to do this only for the DT case, I think. Also, once we get rid
of the edma_soc_info dependency, just pass edma_cc[] directly
Re: [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
On 14/05/14 00:32, Tony Lindgren wrote:
+lcd0 {
+ enable-gpios = gpio5 24 GPIO_ACTIVE_HIGH;/* gpio152, lcd INI */
+ reset-gpios = gpio5 27 GPIO_ACTIVE_HIGH; /* gpio155, lcd RESB */
+ /*
+ * The LCD is sideways, so we want the VGA mode instead of
+ * QVGA mode. Probably also want to have omapfb.rotate=3
+ * in the kernel cmdline until there's a binding for that.
+ */
+ mode-gpios = gpio5 26 GPIO_ACTIVE_LOW /* gpio154, lcd MO */
+ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd UD */
I don't think that is correct. The panel bindings should define what the
first mode-gpio means. Looking at the panel spec, I think the definition
should be enable QVGA mode. And in the board's dts above, the
GPIO_ACTIVE_x should tell which is one is correct polarity for QVGA
mode. Which is GPIO_ACTIVE_HIGH here.
If we want to tell the panel driver to use QVGA mode, we should do that
explicitly with a flag, not by hacking the GPIO polarities. It's the
panel driver's job to set the GPIO.
So in the previous mail I suggested the 'vga-mode' flag, but I think we
need actually two flags for each GPIO: one that's used to tell the
driver which mode we want, which is used if the panel driver has control
for the GPIO, and the other that tells which is the hardwired setting.
Then again, the two cases are exclusive, so maybe a single flag per mode
pin is ok. So, for the MO pin, we could have 'qvga-mode' flag in the
.dts, which means:
If there is MO gpio, set MO high. If there's no MO gpio, presume MO pin
is pulled up
Of course, one could argue that, in case MO is controlled with GPIO, the
'qvga-mode' flag is about SW level configuration, not hardware...
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v2 3/5] dt/bindings: ti,edma: Remove redundant properties from documentation
+ DT bindings maintainers On Thursday 15 May 2014 01:48 PM, Peter Ujfalusi wrote: On 05/15/2014 11:01 AM, Arnd Bergmann wrote: On Tuesday 13 May 2014 13:30:30 Peter Ujfalusi wrote: From CCCFG register of eDMA3 we can get all the needed information for the driver about the IP: Number of channels: NUM_DMACH Number of regions: NUM_REGN Number of slots (PaRAM sets): NUM_PAENTRY Number of TC/EQ: NUM_EVQUE The ti,edma-regions; ti,edma-slots and dma-channels in DT are redundant since the very same information can be obtained from the HW. The mentioned properties can be removed from the binding document. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com I wonder if we should keep them listed as optional properties so you can have a dtb file that still works with older kernels which need them. What you do is an incompatible change to the binding, which we shouldn't do lightly. Any new dts files don't need this information of course, but as a general rule, I'd rather keep things like this around unless we already have to enforce an ABI break that is well documented. We could keep them as optional, or to be precise: ignored properties since we are not going to even look at them in the future. But I do not really see the reason to do so. With this change new kernels will boot with old DTB - if it can not be changed which I have not seen yet. Sure old kernel would not boot with this change, but why would you downgrade the kernel and update the DTB on a board? Bisecting is not a good reason since the bug you might be hunting for could be in the DTS or in the kernel code so you need to update both of them to be sure you reach the commit you are looking for. Agree with Peter here. The bisecting corner case can hopefully be handled by appended DTB even if the original DTB was ROMed. Thanks, Sekhar -- 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: RCU stall on panda
On 05/15/2014 10:44 AM, Alex Shi wrote: On 05/13/2014 11:32 PM, Tony Lindgren wrote: * Alex Shi alex@linaro.org [140512 23:37]: On 05/13/2014 05:21 AM, Tony Lindgren wrote: * Paul E. McKenney paul...@linux.vnet.ibm.com [140505 11:11]: On Mon, May 05, 2014 at 05:39:43PM +0800, Alex Shi wrote: I keep seeing the RCU stall problem on panda board from 3.10 kernel to latest upstream kernel and google find some one report it before: https://lkml.org/lkml/2012/9/20/519 Is it the hardware issue or a real software problem? I cannot distinguish between hardware and software from the trace below, but given that you are also seeing a soft lockup, either way you do appear to have a real problem as opposed to an RCU CPU stall warning false positive. Looks like you have CPU_IDLE enabled on panda. Hangs with current linux next with CPU_IDLE are currently being discussed on the linux-omap list in thread omap4-panda-es boot issues with v3.15-rc4 I've seen occasional system hangs, and I've also noticed that doing ctrl-a-f h or ctrl-a-f l for sysrq backtrace can unlock the system producing similar errors to the below. Thanks a lot for the info. In fact, the oops keeps in upstream kernel from 3.10 to latest. Care to test if the revert of commit cb7094 Santosh posted as [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled solves the problem for you? After enable this patch, system maybe hang in idle. :( Hi Alex, do you mean even with this revert applied, the board hangs in idle ? -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ 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 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
Hi Nishanth, On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote: On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Roger, On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote: Hi Kishon, On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote: APLL used by PCIE phy can either use external clock as input or the clock from DPLL. Added support for the APLL to use external clock as input here. Cc: Rajendra Nayak rna...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++ drivers/phy/phy-ti-pipe3.c | 75 ++ 2 files changed, 52 insertions(+), 27 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index bc9afb5..d50f8ee 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -76,6 +76,10 @@ Required properties: * dpll_ref_m2 - external dpll ref clk * phy-div - divider for apll * div-clk - apll clock + * apll_mux - mux for pcie apll + * refclk_ext - external reference clock for pcie apll + - ti,ext-clk: To specifiy if PCIE apll should use external clock. Applicable + only to PCIE PHY. Instead of specifying both clock sources dpll_ref_clock, refclk_ext and then specifying a 3rd control option ti,ext-clk to select one of the 2 sources, why can't the DT just supply one clock source, i.e. the one that is being used in the board instance? The driver should then just configure the clock rate that is needed at that node. Shouldn't the clock framework automatically take care of muxing and parent rates? Want the dt to have all the clocks used by the controller. ti,ext-clk should go in the board dt file (suggested by Nishanth). The point is at some point later if some one wants to change the clock source, it should be a simple enabling ti,ext-clk flag instead of finding the clock phandle etc.. Wonder if that is implicit by the presence of refclk_ext in the clocks provided? IMO the presence of refclk_ext is useless unless the board indicates it provides the clock source. refclk_ext holds phandle for *fixed-clock*, so irrespective of whether the board provides a clock or not, it can have that handle for configuring in PRCM. However if the board does not provide the clock source, configuring refclk_ext in PRCM is useless. 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 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
On 14/05/14 19:02, Tony Lindgren wrote: The video paths of the panels and encoders are connected using the v4l2 style ports/endpoints. We can use those to see what display controller a panel is connected to, but only after the panel driver has already probed. We don't have control for the actual probing, as that happens with whatever the control bus is for the display component. OK. So with generic panels, you can just let the panels probe with the right compatible flag then and let the ports/endpoints registration to figure out if the panel is usable for the display controller in question. I'm not sure what you mean here. Do you mean with the future common display framework? There's no need to figure out anything there, as supposedly the .dts has been written correctly and the panel and the display controller work together. If you mean with the current kernel, there's still nothing to figure out. We can have only single driver with a particular compatible string. And as our current drivers are omap specific, it makes sense to have their compatible string be something omap-ish. And if the .dts file connects the display controller and the panel, then they must be usable together. Well it seems at least the reset and enable pin standard from that binding can be kept. Only enable gpio there. But even that's vague. Do you turn on the power before or after setting the enable gpio? How long delay should be between the power and the gpio? Different panels have different rules for the power-up. Sure, it's a complex problem. But for the enable gpio.. Maybe the enable GPIO should be treated as a regulator? That would allow specifying first the source regulator startup delay, and then the panel has it's own startup delay. Well... I don't know. Sounds rather hacky to me. We have the option to have a specific driver for this panel, and that driver can handle all the delays and power-up sequences just right in a clean manner. But I'm not really familiar with using extending current bindings, and making new bindings compatible with old ones. Can you explain why it'd be good to have the sharp panel bindings compatible with simple-panel? In what kind of scenario would it be used? Ideally the panel binding just describes the panel and it should not matter which display controller it is a child of. Yes, but that means the panel bindings need to have enough information so that all display controllers can use it. Simple-panel bindings do not have enough information. The simple-panel bindings do not have information about the video bus input, and it doesn't even have information about the resolution or bitdepth of the panel. Some of that you can hide into the panel driver based on the compatible flag. So why not already do something like this in the .dts files instead of the remapping: compatible = sharp,ls037v7dw01-omap-dss, sharp,ls037v7dw01; And drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c would only claim to be compatible with sharp,ls037v7dw01-omap-dss. Then when the common panel framework is available, you can stop parsing sharp,ls037v7dw01-omap-dss but the .dts files don't need to be changed and it's fine to keep sharp,ls037v7dw01-omap-dss in the .dts files. Hmm, I don't see how this relates to the simple-panel bindings. But you're right, having sharp,ls037v7dw01-omap-dss in the .dts is an alternative for the compatible-string conversion we do now. I guess it's a matter of taste, but I rather hide it inside the kernel, in an internal omapdss file, than pollute the .dts files with those compatible strings. So I'm still asking, if we create sharp bindings that use the same properties as the simple-panel bindings, and define that sharp panel is compatible with simple-panel, what kind of scenario in practice would it be used in? Well with the above example, just by dss with sharp,ls037v7dw01-omap-dss until some other SoC notices it can use the GPIO parts of the panel code at least :) Would the scenario be some other OS, that doesn't have a driver for the sharp panel, but has a driver for the simple-panel? That would only work if the sharp panel hardware is setup so that only the enable gpio is needed, so that quite a narrow definition of compatible. That's where we can use the compatible flags and just avoid parsing the generic compatible flag unless some common framework is available. Hmm, sorry, I don't follow. My question was about the simple-panel bindings, not common display framework. You were saying that the sharp bindings should be compatible with simple-panel bindings. I'm still trying to understand what benefit does that give us. As I see it, the sharp panel could be used with the simple-panel bindings only in certain special case, where all the mode pins and the reset are hardwired in the board hardware, and they are hardwired in a certain state (all hardwired low, probably), which matches what the
Re: [PATCH 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
On 05/15/2014 12:15 PM, Kishon Vijay Abraham I wrote: Hi Nishanth, On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote: On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Roger, On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote: Hi Kishon, On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote: APLL used by PCIE phy can either use external clock as input or the clock from DPLL. Added support for the APLL to use external clock as input here. Cc: Rajendra Nayak rna...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++ drivers/phy/phy-ti-pipe3.c | 75 ++ 2 files changed, 52 insertions(+), 27 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index bc9afb5..d50f8ee 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -76,6 +76,10 @@ Required properties: * dpll_ref_m2 - external dpll ref clk * phy-div - divider for apll * div-clk - apll clock + * apll_mux - mux for pcie apll + * refclk_ext - external reference clock for pcie apll + - ti,ext-clk: To specifiy if PCIE apll should use external clock. Applicable + only to PCIE PHY. Instead of specifying both clock sources dpll_ref_clock, refclk_ext and then specifying a 3rd control option ti,ext-clk to select one of the 2 sources, why can't the DT just supply one clock source, i.e. the one that is being used in the board instance? The driver should then just configure the clock rate that is needed at that node. Shouldn't the clock framework automatically take care of muxing and parent rates? Want the dt to have all the clocks used by the controller. ti,ext-clk should go in the board dt file (suggested by Nishanth). The point is at some point later if some one wants to change the clock source, it should be a simple enabling ti,ext-clk flag instead of finding the clock phandle etc.. Wonder if that is implicit by the presence of refclk_ext in the clocks provided? IMO the presence of refclk_ext is useless unless the board indicates it provides the clock source. refclk_ext holds phandle for *fixed-clock*, so irrespective of whether the board provides a clock or not, it can have that handle for configuring in PRCM. However if the board does not provide the clock source, configuring refclk_ext in PRCM is useless. I think what Nishant meant is that if refclk_ext is provided it means that the driver should use that over dpll_ref_clock so no need of a separate ti,ext-clk flag. 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
[PATCH] usb: dwc3: gadget: check link trb after free_slot is increased
In ISOC transfers, when free_slot points to the last TRB (i.e. Link TRB), and all queued requests meet Missed Interval Isoc error, busy_slot points to trb0. busy_slot-trb0 trb1 ... free_slot-trb31(Link TRB) After end transfer and receiving the XferNotReady event, trb_left is caculated as 1 which is wrong, and no TRB will be primed to the endpoint. The root cause is free_slot is not increased the same way as busy_slot. When busy_slot is increased by one, it checks if points to a link TRB after increasement, but free_slot checks it before increasement. free_slot should behave the same as busy_slot to make the trb_left caculation correct. Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com Signed-off-by: Jiebing Li jiebing...@intel.com --- drivers/usb/dwc3/gadget.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 54da8c8..2ebe82b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -828,10 +828,6 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep, length, last ? last : , chain ? chain : ); - /* Skip the LINK-TRB on ISOC */ - if (((dep-free_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1) - usb_endpoint_xfer_isoc(dep-endpoint.desc)) - dep-free_slot++; trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK]; @@ -843,6 +839,10 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep, } dep-free_slot++; + /* Skip the LINK-TRB on ISOC */ + if (((dep-free_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1) + usb_endpoint_xfer_isoc(dep-endpoint.desc)) + dep-free_slot++; trb-size = DWC3_TRB_SIZE_LENGTH(length); trb-bpl = lower_32_bits(dma); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] OMAPDSS: DT support for panel-lgphilips-lb035q02
Hi, This adds DT support to panel-lgphilips-lb035q02. Compile tested only. This panel is used on some Overo boards (alto35, if I'm not mistaken). Tomi Tomi Valkeinen (3): OMAPDSS: panel-lgphilips-lb035q02: use gpiod for enable gpio OMAPDSS: panel-lgphilips-lb035q02: Add DT support Doc/DT: Add binding doc for lgphilips,lb035q02.txt .../bindings/video/lgphilips,lb035q02.txt | 33 ++ .../omap2/displays-new/panel-lgphilips-lb035q02.c | 76 +- 2 files changed, 94 insertions(+), 15 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt -- 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 1/3] OMAPDSS: panel-lgphilips-lb035q02: use gpiod for enable gpio
The new gpiod API supports automatic handling of active-high/active-low
with DT. To make it possible to use that when booting with DT, change
the driver's handling of the enable GPIO to use gpiod.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../omap2/displays-new/panel-lgphilips-lb035q02.c | 32 --
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
index 2e6b513222d9..6e6acd696a70 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
@@ -50,9 +50,10 @@ struct panel_drv_data {
struct omap_video_timings videomode;
- int reset_gpio;
+ /* used for non-DT boot, to be removed */
int backlight_gpio;
- int enable_gpio;
+
+ struct gpio_desc *enable_gpio;
};
#define to_panel_data(p) container_of(p, struct panel_drv_data, dssdev)
@@ -165,8 +166,8 @@ static int lb035q02_enable(struct omap_dss_device *dssdev)
if (r)
return r;
- if (gpio_is_valid(ddata-enable_gpio))
- gpio_set_value_cansleep(ddata-enable_gpio, 1);
+ if (ddata-enable_gpio)
+ gpiod_set_value_cansleep(ddata-enable_gpio, 1);
if (gpio_is_valid(ddata-backlight_gpio))
gpio_set_value_cansleep(ddata-backlight_gpio, 1);
@@ -184,8 +185,8 @@ static void lb035q02_disable(struct omap_dss_device *dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (gpio_is_valid(ddata-enable_gpio))
- gpio_set_value_cansleep(ddata-enable_gpio, 0);
+ if (ddata-enable_gpio)
+ gpiod_set_value_cansleep(ddata-enable_gpio, 0);
if (gpio_is_valid(ddata-backlight_gpio))
gpio_set_value_cansleep(ddata-backlight_gpio, 0);
@@ -243,6 +244,7 @@ static int lb035q02_probe_pdata(struct spi_device *spi)
const struct panel_lb035q02_platform_data *pdata;
struct panel_drv_data *ddata = dev_get_drvdata(spi-dev);
struct omap_dss_device *dssdev, *in;
+ int r;
pdata = dev_get_platdata(spi-dev);
@@ -260,10 +262,19 @@ static int lb035q02_probe_pdata(struct spi_device *spi)
dssdev = ddata-dssdev;
dssdev-name = pdata-name;
- ddata-enable_gpio = pdata-enable_gpio;
+ r = devm_gpio_request_one(spi-dev, pdata-enable_gpio,
+ GPIOF_OUT_INIT_LOW, panel enable);
+ if (r)
+ goto err_gpio;
+
+ ddata-enable_gpio = gpio_to_desc(pdata-enable_gpio);
+
ddata-backlight_gpio = pdata-backlight_gpio;
return 0;
+err_gpio:
+ omap_dss_put_device(ddata-in);
+ return r;
}
static int lb035q02_panel_spi_probe(struct spi_device *spi)
@@ -288,13 +299,6 @@ static int lb035q02_panel_spi_probe(struct spi_device *spi)
return -ENODEV;
}
- if (gpio_is_valid(ddata-enable_gpio)) {
- r = devm_gpio_request_one(spi-dev, ddata-enable_gpio,
- GPIOF_OUT_INIT_LOW, panel enable);
- if (r)
- goto err_gpio;
- }
-
if (gpio_is_valid(ddata-backlight_gpio)) {
r = devm_gpio_request_one(spi-dev, ddata-backlight_gpio,
GPIOF_OUT_INIT_LOW, panel backlight);
--
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 3/3] Doc/DT: Add binding doc for lgphilips,lb035q02.txt
Add DT bindings documentation for LG.Philips LB035Q02 LCD panel.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
.../bindings/video/lgphilips,lb035q02.txt | 33 ++
1 file changed, 33 insertions(+)
create mode 100644
Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
diff --git a/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
new file mode 100644
index ..1a1e653e5407
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
@@ -0,0 +1,33 @@
+LG.Philips LB035Q02 Panel
+=
+
+Required properties:
+- compatible: lgphilips,lb035q02
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- label: a symbolic name for the panel
+
+Required nodes:
+- Video port for DPI input
+
+Example
+---
+
+lcd-panel: panel@0 {
+ compatible = lgphilips,lb035q02;
+ reg = 0;
+ spi-max-frequency = 10;
+ spi-cpol;
+ spi-cpha;
+
+ label = lcd;
+
+ enable-gpios = gpio7 7 0;
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+ };
+};
--
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/3] OMAPDSS: panel-lgphilips-lb035q02: Add DT support
Add DT support for panel-lgphilips-lb035q02.
We disable the use of the backlight_gpio as it should be handled via
backlight framework with DT boots.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../omap2/displays-new/panel-lgphilips-lb035q02.c | 44 +-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
index 6e6acd696a70..76c4fdc51c31 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-lgphilips-lb035q02.c
@@ -159,7 +159,8 @@ static int lb035q02_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);
r = in-ops.dpi-enable(in);
@@ -277,6 +278,35 @@ err_gpio:
return r;
}
+static int lb035q02_probe_of(struct spi_device *spi)
+{
+ struct device_node *node = spi-dev.of_node;
+ struct panel_drv_data *ddata = dev_get_drvdata(spi-dev);
+ struct omap_dss_device *in;
+ struct gpio_desc *gpio;
+
+ gpio = devm_gpiod_get(spi-dev, enable);
+ if (IS_ERR(gpio)) {
+ dev_err(spi-dev, failed to parse enable gpio\n);
+ return PTR_ERR(gpio);
+ } else {
+ gpiod_direction_output(gpio, 0);
+ ddata-enable_gpio = gpio;
+ }
+
+ ddata-backlight_gpio = -ENOENT;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(spi-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int lb035q02_panel_spi_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -295,6 +325,10 @@ static int lb035q02_panel_spi_probe(struct spi_device *spi)
r = lb035q02_probe_pdata(spi);
if (r)
return r;
+ } else if (spi-dev.of_node) {
+ r = lb035q02_probe_of(spi);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -346,6 +380,13 @@ static int lb035q02_panel_spi_remove(struct spi_device
*spi)
return 0;
}
+static const struct of_device_id lb035q02_of_match[] = {
+ { .compatible = omapdss,lgphilips,lb035q02, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, lb035q02_of_match);
+
static struct spi_driver lb035q02_spi_driver = {
.probe = lb035q02_panel_spi_probe,
.remove = lb035q02_panel_spi_remove,
@@ -357,6 +398,7 @@ static struct spi_driver lb035q02_spi_driver = {
module_spi_driver(lb035q02_spi_driver);
+MODULE_ALIAS(spi:lgphilips,lb035q02);
MODULE_AUTHOR(Tomi Valkeinen tomi.valkei...@ti.com);
MODULE_DESCRIPTION(LG.Philips LB035Q02 LCD Panel driver);
MODULE_LICENSE(GPL);
--
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: [PATCH 1/1] ARM: dts: am437x-gp-evm: Add ethernet support for GP EVM
On Tuesday 13 May 2014 10:50 PM, Tony Lindgren wrote:
* Mugunthan V N mugunthan...@ti.com [140507 02:31]:
Add CPSW ethernet support for AM437x GP EVM which has one slave pinned out
Signed-off-by: Mugunthan V N mugunthan...@ti.com
---
arch/arm/boot/dts/am437x-gp-evm.dts | 72
+
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 2e0c636..30ace1b 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -98,6 +98,58 @@
0x264 (PIN_INPUT_PULLUP | MUX_MODE7) /*
spi2_d0.gpio3_22 */
;
};
+
+cpsw_default: cpsw_default {
+pinctrl-single,pins =
+/* Slave 1 */
+0x114 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txen.rgmii1_txen */
+0x118 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxdv.rgmii1_rxctl */
+0x11c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_txd3 */
+0x120 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_txd2 */
+0x124 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd1.rgmii1_txd1 */
+0x128 (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txd0.rgmii1_txd0 */
+0x12c (PIN_OUTPUT_PULLDOWN | MUX_MODE2) /*
mii1_txclk.rmii1_tclk */
+0x130 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxclk.rmii1_rclk */
+0x134 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rxd3 */
+0x138 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rxd2 */
+0x13c (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd1.rgmii1_rxd1 */
+0x140 (PIN_INPUT_PULLDOWN | MUX_MODE2) /*
mii1_rxd0.rgmii1_rxd0 */
+;
+};
+
+cpsw_sleep: cpsw_sleep {
+pinctrl-single,pins =
+/* Slave 1 reset value */
+0x114 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x118 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x11c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x120 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x124 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x128 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x12c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x130 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x134 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x138 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x13c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x140 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+;
+};
Just a nitpick comment to make things more readable. Can you please add
the comments for these pins too so people can cross check them against
the documentation easier?
+davinci_mdio_default: davinci_mdio_default {
+pinctrl-single,pins =
+/* MDIO */
+0x148 (PIN_INPUT_PULLUP | SLEWCTRL_FAST | MUX_MODE0)
/* mdio_data.mdio_data */
+0x14c (PIN_OUTPUT_PULLUP | MUX_MODE0)
/* mdio_clk.mdio_clk */
+;
+};
+
+davinci_mdio_sleep: davinci_mdio_sleep {
+pinctrl-single,pins =
+/* MDIO reset value */
+0x148 (PIN_INPUT_PULLDOWN | MUX_MODE7)
+0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
+;
+};
};
And here too please.
Will add the comments and post the patch again
Regards
Mugunthan V 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 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
On Thu, May 15, 2014 at 4:25 AM, Roger Quadros rog...@ti.com wrote: On 05/15/2014 12:15 PM, Kishon Vijay Abraham I wrote: Hi Nishanth, On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote: On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Roger, On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote: Hi Kishon, On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote: APLL used by PCIE phy can either use external clock as input or the clock from DPLL. Added support for the APLL to use external clock as input here. Cc: Rajendra Nayak rna...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++ drivers/phy/phy-ti-pipe3.c | 75 ++ 2 files changed, 52 insertions(+), 27 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index bc9afb5..d50f8ee 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -76,6 +76,10 @@ Required properties: * dpll_ref_m2 - external dpll ref clk * phy-div - divider for apll * div-clk - apll clock + * apll_mux - mux for pcie apll + * refclk_ext - external reference clock for pcie apll + - ti,ext-clk: To specifiy if PCIE apll should use external clock. Applicable + only to PCIE PHY. Instead of specifying both clock sources dpll_ref_clock, refclk_ext and then specifying a 3rd control option ti,ext-clk to select one of the 2 sources, why can't the DT just supply one clock source, i.e. the one that is being used in the board instance? The driver should then just configure the clock rate that is needed at that node. Shouldn't the clock framework automatically take care of muxing and parent rates? Want the dt to have all the clocks used by the controller. ti,ext-clk should go in the board dt file (suggested by Nishanth). The point is at some point later if some one wants to change the clock source, it should be a simple enabling ti,ext-clk flag instead of finding the clock phandle etc.. Wonder if that is implicit by the presence of refclk_ext in the clocks provided? IMO the presence of refclk_ext is useless unless the board indicates it provides the clock source. refclk_ext holds phandle for *fixed-clock*, so irrespective of whether the board provides a clock or not, it can have that handle for configuring in PRCM. However if the board does not provide the clock source, configuring refclk_ext in PRCM is useless. I think what Nishant meant is that if refclk_ext is provided it means that the driver should use that over dpll_ref_clock so no need of a separate ti,ext-clk flag. yes, thank you for clarifying - it does indeed redundant to have ti,ext-clk. and apologies on being a little obscure in the comment. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
On Thu, May 15, 2014 at 1:08 AM, Mike Turquette mturque...@linaro.org wrote: Quoting Tomi Valkeinen (2014-05-12 05:13:51) On 12/05/14 15:02, Tero Kristo wrote: On 05/08/2014 12:06 PM, Tomi Valkeinen wrote: The current DPLL code does not try to round the clock rate, and instead returns an error if the requested clock rate cannot be produced exactly by the DPLL. It could be argued that this is a bug, but as the current drivers may depend on that behavior, a new flag 'ti,round-rate' is added which enables clock rate rounding. Someone could probably argue that this flag is not a hardware feature, I fully agree. but instead is used to describe linux-kernel behavior, and would probably be frowned upon by the DT enthusiasts. Othen than that, I like this approach better than a global setting, but would like second opinions here. I think the dpll code should always do rounding. That's what round_rate() is supposed to do, afaik. The current behavior of not rounding and returning an error is a bug in my opinion. From include/linux/clk.h: /** * clk_round_rate - adjust a rate to the exact rate a clock can provide * @clk: clock source * @rate: desired clock rate in Hz * * Returns rounded clock rate in Hz, or negative errno. */ long clk_round_rate(struct clk *clk, unsigned long rate); Definitely not rounding the rate is a bug, with respect to the API definition. Has anyone tried making the new flag as the default behavior and seeing if anything breaks? For those users of the omapconf tool I enjoy doing something like the following: boot current, buggy behavior omapconf dump prcm old boot with Tomi's flag enabled for all DPLLs by default omapconf dump prcm new diff -u old new This should reveal any deltas, assuming the board boots and doesn't let magic smoke out. it would probably help for omap4,5,dra7, but AM335x, OMAP3 are not supported on omapconf - yet. just a side note. omapconf: https://github.com/omapconf/omapconf 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 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
Hi Nishant, On Thursday 15 May 2014 05:16 PM, Nishanth Menon wrote: On Thu, May 15, 2014 at 4:25 AM, Roger Quadros rog...@ti.com wrote: On 05/15/2014 12:15 PM, Kishon Vijay Abraham I wrote: Hi Nishanth, On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote: On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Roger, On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote: Hi Kishon, On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote: APLL used by PCIE phy can either use external clock as input or the clock from DPLL. Added support for the APLL to use external clock as input here. Cc: Rajendra Nayak rna...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++ drivers/phy/phy-ti-pipe3.c | 75 ++ 2 files changed, 52 insertions(+), 27 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index bc9afb5..d50f8ee 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -76,6 +76,10 @@ Required properties: * dpll_ref_m2 - external dpll ref clk * phy-div - divider for apll * div-clk - apll clock + * apll_mux - mux for pcie apll + * refclk_ext - external reference clock for pcie apll + - ti,ext-clk: To specifiy if PCIE apll should use external clock. Applicable + only to PCIE PHY. Instead of specifying both clock sources dpll_ref_clock, refclk_ext and then specifying a 3rd control option ti,ext-clk to select one of the 2 sources, why can't the DT just supply one clock source, i.e. the one that is being used in the board instance? The driver should then just configure the clock rate that is needed at that node. Shouldn't the clock framework automatically take care of muxing and parent rates? Want the dt to have all the clocks used by the controller. ti,ext-clk should go in the board dt file (suggested by Nishanth). The point is at some point later if some one wants to change the clock source, it should be a simple enabling ti,ext-clk flag instead of finding the clock phandle etc.. Wonder if that is implicit by the presence of refclk_ext in the clocks provided? IMO the presence of refclk_ext is useless unless the board indicates it provides the clock source. refclk_ext holds phandle for *fixed-clock*, so irrespective of whether the board provides a clock or not, it can have that handle for configuring in PRCM. However if the board does not provide the clock source, configuring refclk_ext in PRCM is useless. I think what Nishant meant is that if refclk_ext is provided it means that the driver should use that over dpll_ref_clock so no need of a separate ti,ext-clk flag. yes, thank you for clarifying - it does indeed redundant to have ti,ext-clk. and apologies on being a little obscure in the comment. Irrespective of whether external reference clock is used or not, all DRA7 (apll) has an input for external reference clock (and also a PRCM register for programming it) and it has to be specified in dt no? 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] ARM: edma: Clean up and simplify the code around irq request
+ ARM SoC team
On Tuesday 13 May 2014 12:56 PM, Peter Ujfalusi wrote:
Get the two interrupt line number at the same time by merging the two
instance of if(node){}else{} places.
replace the pdev-dev with the already existing dev which makes it possible
to collapse lines with devm_request_irq()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
Arnd, Olof, Kevin,
Do you mind applying this directly for v3.16? I do not have anything
else queued ATM so not sending a pull request.
Thanks,
Sekhar
--
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 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
On Thu, May 15, 2014 at 6:59 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Nishant, On Thursday 15 May 2014 05:16 PM, Nishanth Menon wrote: On Thu, May 15, 2014 at 4:25 AM, Roger Quadros rog...@ti.com wrote: On 05/15/2014 12:15 PM, Kishon Vijay Abraham I wrote: Hi Nishanth, On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote: On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi Roger, On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote: Hi Kishon, On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote: APLL used by PCIE phy can either use external clock as input or the clock from DPLL. Added support for the APLL to use external clock as input here. Cc: Rajendra Nayak rna...@ti.com Cc: Tero Kristo t-kri...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++ drivers/phy/phy-ti-pipe3.c | 75 ++ 2 files changed, 52 insertions(+), 27 deletions(-) diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt index bc9afb5..d50f8ee 100644 --- a/Documentation/devicetree/bindings/phy/ti-phy.txt +++ b/Documentation/devicetree/bindings/phy/ti-phy.txt @@ -76,6 +76,10 @@ Required properties: * dpll_ref_m2 - external dpll ref clk * phy-div - divider for apll * div-clk - apll clock + * apll_mux - mux for pcie apll + * refclk_ext - external reference clock for pcie apll + - ti,ext-clk: To specifiy if PCIE apll should use external clock. Applicable + only to PCIE PHY. Instead of specifying both clock sources dpll_ref_clock, refclk_ext and then specifying a 3rd control option ti,ext-clk to select one of the 2 sources, why can't the DT just supply one clock source, i.e. the one that is being used in the board instance? The driver should then just configure the clock rate that is needed at that node. Shouldn't the clock framework automatically take care of muxing and parent rates? Want the dt to have all the clocks used by the controller. ti,ext-clk should go in the board dt file (suggested by Nishanth). The point is at some point later if some one wants to change the clock source, it should be a simple enabling ti,ext-clk flag instead of finding the clock phandle etc.. Wonder if that is implicit by the presence of refclk_ext in the clocks provided? IMO the presence of refclk_ext is useless unless the board indicates it provides the clock source. refclk_ext holds phandle for *fixed-clock*, so irrespective of whether the board provides a clock or not, it can have that handle for configuring in PRCM. However if the board does not provide the clock source, configuring refclk_ext in PRCM is useless. I think what Nishant meant is that if refclk_ext is provided it means that the driver should use that over dpll_ref_clock so no need of a separate ti,ext-clk flag. yes, thank you for clarifying - it does indeed redundant to have ti,ext-clk. and apologies on being a little obscure in the comment. Irrespective of whether external reference clock is used or not, all DRA7 (apll) has an input for external reference clock (and also a PRCM register for programming it) and it has to be specified in dt no? Why is that a binding for ti-phy? that is a problem for the APLL clock driver (selecting it's own source). PHY properties should describe itself - let the bindings of the APLL describe itself. please dont mix the two up. 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 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
Hi,
On Thursday 15 May 2014 05:42 PM, Nishanth Menon wrote:
On Thu, May 15, 2014 at 6:59 AM, Kishon Vijay Abraham I kis...@ti.com wrote:
Hi Nishant,
On Thursday 15 May 2014 05:16 PM, Nishanth Menon wrote:
On Thu, May 15, 2014 at 4:25 AM, Roger Quadros rog...@ti.com wrote:
On 05/15/2014 12:15 PM, Kishon Vijay Abraham I wrote:
Hi Nishanth,
On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote:
On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi Roger,
On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote:
Hi Kishon,
On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
APLL used by PCIE phy can either use external clock as input or the
clock
from DPLL. Added support for the APLL to use external clock as input
here.
Cc: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++
drivers/phy/phy-ti-pipe3.c | 75
++
2 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index bc9afb5..d50f8ee 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -76,6 +76,10 @@ Required properties:
* dpll_ref_m2 - external dpll ref clk
* phy-div - divider for apll
* div-clk - apll clock
+ * apll_mux - mux for pcie apll
+ * refclk_ext - external reference clock for pcie apll
+ - ti,ext-clk: To specifiy if PCIE apll should use external clock.
Applicable
+ only to PCIE PHY.
Instead of specifying both clock sources dpll_ref_clock,
refclk_ext and then specifying a 3rd control option ti,ext-clk to
select one of the 2 sources, why can't the DT just supply one clock
source, i.e. the one that is being used in the board instance? The
driver should then just configure the clock rate that is needed at
that node. Shouldn't the clock framework automatically take care of
muxing and parent rates?
Want the dt to have all the clocks used by the controller. ti,ext-clk
should
go in the board dt file (suggested by Nishanth).
The point is at some point later if some one wants to change the clock
source,
it should be a simple enabling ti,ext-clk flag instead of finding the
clock
phandle etc..
Wonder if that is implicit by the presence of refclk_ext in the
clocks provided?
IMO the presence of refclk_ext is useless unless the board indicates it
provides the clock source.
refclk_ext holds phandle for *fixed-clock*, so irrespective of whether the
board provides a clock or not, it can have that handle for configuring in
PRCM.
However if the board does not provide the clock source, configuring
refclk_ext
in PRCM is useless.
I think what Nishant meant is that if refclk_ext is provided it means
that the driver
should use that over dpll_ref_clock so no need of a separate
ti,ext-clk flag.
yes, thank you for clarifying - it does indeed redundant to have
ti,ext-clk. and apologies on being a little obscure in the comment.
Irrespective of whether external reference clock is used or not, all DRA7
(apll) has an input for external reference clock (and also a PRCM register
for
programming it) and it has to be specified in dt no?
Why is that a binding for ti-phy? that is a problem for the APLL clock
driver (selecting it's own source). PHY properties should describe
itself - let the bindings of the APLL describe itself. please dont
mix the two up.
The apll clock node is like this
apll_pcie_in_clk_mux: apll_pcie_in_clk_mux@4ae06118 {
compatible = mux-clock;
clocks = dpll_pcie_ref_m2ldo_ck, pciesref_acs_clk_ck;
#clock-cells = 0;
reg = 0x4a00821c 0x4;
bit-mask = 0x80;
};
The external reference clock is denoted by *pciesref_acs_clk_ck*.
refclk_ext holds the phandle to *pciesref_acs_clk_ck* and is used in
clk_set_parent to set the parent of apll mux.
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 1/3] clk: ti: add 'ti,round-rate' flag
On 15/05/14 09:08, Mike Turquette wrote: Quoting Tomi Valkeinen (2014-05-12 05:13:51) On 12/05/14 15:02, Tero Kristo wrote: On 05/08/2014 12:06 PM, Tomi Valkeinen wrote: The current DPLL code does not try to round the clock rate, and instead returns an error if the requested clock rate cannot be produced exactly by the DPLL. It could be argued that this is a bug, but as the current drivers may depend on that behavior, a new flag 'ti,round-rate' is added which enables clock rate rounding. Someone could probably argue that this flag is not a hardware feature, I fully agree. but instead is used to describe linux-kernel behavior, and would probably be frowned upon by the DT enthusiasts. Othen than that, I like this approach better than a global setting, but would like second opinions here. I think the dpll code should always do rounding. That's what round_rate() is supposed to do, afaik. The current behavior of not rounding and returning an error is a bug in my opinion. From include/linux/clk.h: /** * clk_round_rate - adjust a rate to the exact rate a clock can provide * @clk: clock source * @rate: desired clock rate in Hz * * Returns rounded clock rate in Hz, or negative errno. */ long clk_round_rate(struct clk *clk, unsigned long rate); Definitely not rounding the rate is a bug, with respect to the API definition. Has anyone tried making the new flag as the default behavior and seeing if anything breaks? The v1 of the patch fixed the rounding unconditionally: http://article.gmane.org/gmane.linux.ports.arm.kernel/295077 Paul wanted it optional so that existing drivers would not break. No one knows if there is such a driver, or what would the driver's code look like that would cause an issue. And, as I've pointed out in the above thread, as clk-divider driver doesn't an error code from the dpll driver, my opinion is that such drivers would not work even now. I like v1 more. In any case, I hope we'd get something merged ASAP so that we fix the display AM3xxx boards and we'd still have time to possibly find out if some other driver breaks. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/5] ARM: edma: Get IP information from HW when booting with DT
Hi Sekhar,
On 05/15/2014 11:53 AM, Sekhar Nori wrote:
Hi Peter,
On Tuesday 13 May 2014 04:00 PM, Peter Ujfalusi wrote:
From CCCFG register of eDMA3 we can get all the needed information for the
driver about the IP:
Number of channels: NUM_DMACH
Number of regions: NUM_REGN
Number of slots (PaRAM sets): NUM_PAENTRY
Number of TC/EQ: NUM_EVQUE
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 128
++---
1 file changed, 79 insertions(+), 49 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index fade9ada81f8..1a98f3cd4cd9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -102,7 +102,16 @@
#define PARM_OFFSET(param_no) (EDMA_PARM + ((param_no) 5))
#define EDMA_DCHMAP 0x0100 /* 64 registers */
-#define CHMAP_EXIST BIT(24)
+
+/* CCCFG register */
+#define GET_NUM_DMACH(x)(x 0x7) /* bits 0-2 */
+#define GET_NUM_QDMACH(x) ((x 0x70) 4) /* bits 4-6 */
+#define GET_NUM_INTCH(x)((x 0x700) 8) /* bits 8-10 */
+#define GET_NUM_PAENTRY(x) ((x 0x7000) 12) /* bits 12-14 */
+#define GET_NUM_EVQUE(x)((x 0x7) 16) /* bits 16-18 */
+#define GET_NUM_REGN(x) ((x 0x30) 20) /* bits 20-21 */
+#define CHMAP_EXIST BIT(24)
+#define MP_EXISTBIT(25)
Of these new defines, you do not use GET_NUM_QDMACH(), GET_NUM_INTCH()
and MP_EXIST (at least in this patch). Can you please get rid of them if
not needed? May be its just me but its pretty annoying to search for a
define only to find its never used :)
Sure, I can remove the ones we are not using in the code. I usually prefer to
have full description if the register even if we only use one bit from the
register.
#define EDMA_MAX_DMACH 64
#define EDMA_MAX_PARAMENTRY 512
@@ -1415,6 +1424,68 @@ void edma_clear_event(unsigned channel)
}
EXPORT_SYMBOL(edma_clear_event);
+static int edma_setup_info_from_hw(struct device *dev,
+ struct edma_soc_info *pdata)
+{
+int i;
+u32 value, cccfg, n_tc;
+s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+/* Decode the eDMA3 configuration from CCCFG register */
+cccfg = edma_read(0, EDMA_CCCFG);
You do not handle the second controller here, but its pretty straight
forward to add that by passing the controller number to this function.
The second controller is not handled because in DT boot we only handle 1 cc as
far as I know. I don't know why, but this is how the DT support has been
written and used.
I was wondering why we never read the hardware for this information
before, and strangely enough cannot find any SoC where the CCCFG
register does not publish this information correctly. I have tested on
DA850, DA830, DM365, DM355 and DM6467.
Good question. I was also puzzled about this.
Instead of keeping this specific to OF case, the code can be simplified
much better if we read from hardware all the time. We can directly
populate the equivalent variables in the internal structure 'struct
edma' instead of populating them in 'struct edma_soc_info' and then
copying then over.
Yes, we can switch the non DT boot to this mode as well, true. At first I
wanted to change code which I can test easily. For non DT boot I would need to
set up my old daVinci board ;)
+
+value = GET_NUM_DMACH(cccfg);
+pdata-n_channel = BIT(value + 1);
+
+value = GET_NUM_REGN(cccfg);
+pdata-n_region = BIT(value);
+
+value = GET_NUM_PAENTRY(cccfg);
+pdata-n_slot = BIT(value + 4);
+
+value = GET_NUM_EVQUE(cccfg);
+n_tc = value + 1;
+
+dev_dbg(dev, eDMA3 HW configuration (cccfg: 0x%08x):\n, cccfg);
+dev_dbg(dev, n_channel: %u\n, pdata-n_channel);
+dev_dbg(dev, n_region: %u\n, pdata-n_region);
+dev_dbg(dev, n_slot: %u\n, pdata-n_slot);
+dev_dbg(dev, n_tc: %u\n, n_tc);
+
[snip]
+pdata-n_cc = 1;
+
+queue_tc_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8), GFP_KERNEL);
+if (!queue_tc_map)
+return -ENOMEM;
+
+for (i = 0; i n_tc; i++) {
+queue_tc_map[i][0] = i;
+queue_tc_map[i][1] = i;
+}
+queue_tc_map[i][0] = -1;
+queue_tc_map[i][1] = -1;
+
+pdata-queue_tc_mapping = queue_tc_map;
+
+queue_priority_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+if (!queue_priority_map)
+return -ENOMEM;
+
+for (i = 0; i n_tc; i++) {
+queue_priority_map[i][0] = i;
+queue_priority_map[i][1] = i;
+}
+queue_priority_map[i][0] = -1;
+queue_priority_map[i][1] = -1;
+
+pdata-queue_priority_mapping = queue_priority_map;
+
+pdata-default_queue = 0;
This is part is not really setting up from hardware (rather falling back
to some sane defaults for the DT case). Could you leave them in
Re: [PATCH 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
On 05/15/2014 07:18 AM, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 15 May 2014 05:42 PM, Nishanth Menon wrote:
On Thu, May 15, 2014 at 6:59 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi Nishant,
On Thursday 15 May 2014 05:16 PM, Nishanth Menon wrote:
On Thu, May 15, 2014 at 4:25 AM, Roger Quadros rog...@ti.com wrote:
On 05/15/2014 12:15 PM, Kishon Vijay Abraham I wrote:
Hi Nishanth,
On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote:
On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I
kis...@ti.com wrote:
Hi Roger,
On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote:
Hi Kishon,
On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
APLL used by PCIE phy can either use external clock as input or the
clock
from DPLL. Added support for the APLL to use external clock as input
here.
Cc: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++
drivers/phy/phy-ti-pipe3.c | 75
++
2 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index bc9afb5..d50f8ee 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -76,6 +76,10 @@ Required properties:
* dpll_ref_m2 - external dpll ref clk
* phy-div - divider for apll
* div-clk - apll clock
+ * apll_mux - mux for pcie apll
+ * refclk_ext - external reference clock for pcie apll
+ - ti,ext-clk: To specifiy if PCIE apll should use external clock.
Applicable
+ only to PCIE PHY.
Instead of specifying both clock sources dpll_ref_clock,
refclk_ext and then specifying a 3rd control option ti,ext-clk to
select one of the 2 sources, why can't the DT just supply one clock
source, i.e. the one that is being used in the board instance? The
driver should then just configure the clock rate that is needed at
that node. Shouldn't the clock framework automatically take care of
muxing and parent rates?
Want the dt to have all the clocks used by the controller.
ti,ext-clk should
go in the board dt file (suggested by Nishanth).
The point is at some point later if some one wants to change the clock
source,
it should be a simple enabling ti,ext-clk flag instead of finding
the clock
phandle etc..
Wonder if that is implicit by the presence of refclk_ext in the
clocks provided?
IMO the presence of refclk_ext is useless unless the board indicates it
provides the clock source.
refclk_ext holds phandle for *fixed-clock*, so irrespective of whether
the
board provides a clock or not, it can have that handle for configuring
in PRCM.
However if the board does not provide the clock source, configuring
refclk_ext
in PRCM is useless.
I think what Nishant meant is that if refclk_ext is provided it means
that the driver
should use that over dpll_ref_clock so no need of a separate
ti,ext-clk flag.
yes, thank you for clarifying - it does indeed redundant to have
ti,ext-clk. and apologies on being a little obscure in the comment.
Irrespective of whether external reference clock is used or not, all DRA7
(apll) has an input for external reference clock (and also a PRCM register
for
programming it) and it has to be specified in dt no?
Why is that a binding for ti-phy? that is a problem for the APLL clock
driver (selecting it's own source). PHY properties should describe
itself - let the bindings of the APLL describe itself. please dont
mix the two up.
The apll clock node is like this
apll_pcie_in_clk_mux: apll_pcie_in_clk_mux@4ae06118 {
compatible = mux-clock;
clocks = dpll_pcie_ref_m2ldo_ck, pciesref_acs_clk_ck;
#clock-cells = 0;
reg = 0x4a00821c 0x4;
bit-mask = 0x80;
};
The external reference clock is denoted by *pciesref_acs_clk_ck*.
refclk_ext holds the phandle to *pciesref_acs_clk_ck* and is used in
clk_set_parent to set the parent of apll mux.
So, How about this: if refclk_ext is not defined, dont do setparent,
if it is defined, do setparent.
in short:
Optional Properties:
* refclk_ext - external reference clock for pcie apll - if defined,
used as the parent to apll_mux
That said, my problem in general with this approach(which many folks
have taken of describing parent of clock X in hardware block binding
for Y) is the following:
The binding now has dependency on clock tree hierarchy. What if
towmorrow, we have a tree where refclk_ext parent of muxZ parent of
apll_mux? the binding breaks down. Lets not forget that we consider DT
as an ABI - we dont want to change the binding in the future.
I had always preferred describing parent-child relationship of clocks
by the approach Tero posted:
Re: [PATCH 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
Hi,
On Thursday 15 May 2014 06:03 PM, Nishanth Menon wrote:
On 05/15/2014 07:18 AM, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 15 May 2014 05:42 PM, Nishanth Menon wrote:
On Thu, May 15, 2014 at 6:59 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi Nishant,
On Thursday 15 May 2014 05:16 PM, Nishanth Menon wrote:
On Thu, May 15, 2014 at 4:25 AM, Roger Quadros rog...@ti.com wrote:
On 05/15/2014 12:15 PM, Kishon Vijay Abraham I wrote:
Hi Nishanth,
On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote:
On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I
kis...@ti.com wrote:
Hi Roger,
On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote:
Hi Kishon,
On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
APLL used by PCIE phy can either use external clock as input or the
clock
from DPLL. Added support for the APLL to use external clock as
input here.
Cc: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++
drivers/phy/phy-ti-pipe3.c | 75
++
2 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index bc9afb5..d50f8ee 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -76,6 +76,10 @@ Required properties:
* dpll_ref_m2 - external dpll ref clk
* phy-div - divider for apll
* div-clk - apll clock
+ * apll_mux - mux for pcie apll
+ * refclk_ext - external reference clock for pcie apll
+ - ti,ext-clk: To specifiy if PCIE apll should use external clock.
Applicable
+ only to PCIE PHY.
Instead of specifying both clock sources dpll_ref_clock,
refclk_ext and then specifying a 3rd control option ti,ext-clk
to select one of the 2 sources, why can't the DT just supply one
clock source, i.e. the one that is being used in the board instance?
The driver should then just configure the clock rate that is needed
at that node. Shouldn't the clock framework automatically take care
of muxing and parent rates?
Want the dt to have all the clocks used by the controller.
ti,ext-clk should
go in the board dt file (suggested by Nishanth).
The point is at some point later if some one wants to change the
clock source,
it should be a simple enabling ti,ext-clk flag instead of finding
the clock
phandle etc..
Wonder if that is implicit by the presence of refclk_ext in the
clocks provided?
IMO the presence of refclk_ext is useless unless the board indicates
it
provides the clock source.
refclk_ext holds phandle for *fixed-clock*, so irrespective of whether
the
board provides a clock or not, it can have that handle for configuring
in PRCM.
However if the board does not provide the clock source, configuring
refclk_ext
in PRCM is useless.
I think what Nishant meant is that if refclk_ext is provided it means
that the driver
should use that over dpll_ref_clock so no need of a separate
ti,ext-clk flag.
yes, thank you for clarifying - it does indeed redundant to have
ti,ext-clk. and apologies on being a little obscure in the comment.
Irrespective of whether external reference clock is used or not, all DRA7
(apll) has an input for external reference clock (and also a PRCM register
for
programming it) and it has to be specified in dt no?
Why is that a binding for ti-phy? that is a problem for the APLL clock
driver (selecting it's own source). PHY properties should describe
itself - let the bindings of the APLL describe itself. please dont
mix the two up.
The apll clock node is like this
apll_pcie_in_clk_mux: apll_pcie_in_clk_mux@4ae06118 {
compatible = mux-clock;
clocks = dpll_pcie_ref_m2ldo_ck, pciesref_acs_clk_ck;
#clock-cells = 0;
reg = 0x4a00821c 0x4;
bit-mask = 0x80;
};
The external reference clock is denoted by *pciesref_acs_clk_ck*.
refclk_ext holds the phandle to *pciesref_acs_clk_ck* and is used in
clk_set_parent to set the parent of apll mux.
So, How about this: if refclk_ext is not defined, dont do setparent,
if it is defined, do setparent.
in short:
Optional Properties:
* refclk_ext - external reference clock for pcie apll - if defined,
used as the parent to apll_mux
Ok, will remove ti,ext-clk.
Thanks
Kishon
That said, my problem in general with this approach(which many folks
have taken of describing parent of clock X in hardware block binding
for Y) is the following:
The binding now has dependency on clock tree hierarchy. What if
towmorrow, we have a tree where refclk_ext parent of muxZ parent of
apll_mux? the binding breaks down. Lets not forget that we consider DT
as an ABI - we dont want to change the binding in the future.
I had
Re: [PATCH v2 2/5] ARM: edma: Get IP information from HW when booting with DT
On Thursday 15 May 2014 06:00 PM, Peter Ujfalusi wrote:
The second controller is not handled because in DT boot we only handle 1 cc as
far as I know. I don't know why, but this is how the DT support has been
written and used.
Its just because none of the platforms under heavy development use two
controllers. Joel promised to work on it at some point ;)
I was wondering why we never read the hardware for this information
before, and strangely enough cannot find any SoC where the CCCFG
register does not publish this information correctly. I have tested on
DA850, DA830, DM365, DM355 and DM6467.
Good question. I was also puzzled about this.
Instead of keeping this specific to OF case, the code can be simplified
much better if we read from hardware all the time. We can directly
populate the equivalent variables in the internal structure 'struct
edma' instead of populating them in 'struct edma_soc_info' and then
copying then over.
Yes, we can switch the non DT boot to this mode as well, true. At first I
wanted to change code which I can test easily. For non DT boot I would need to
set up my old daVinci board ;)
I can help testing (and even with writing the DaVinci platform specific
patches).
+ pdata-n_cc = 1;
+
+ queue_tc_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8), GFP_KERNEL);
+ if (!queue_tc_map)
+ return -ENOMEM;
+
+ for (i = 0; i n_tc; i++) {
+ queue_tc_map[i][0] = i;
+ queue_tc_map[i][1] = i;
+ }
+ queue_tc_map[i][0] = -1;
+ queue_tc_map[i][1] = -1;
+
+ pdata-queue_tc_mapping = queue_tc_map;
+
+ queue_priority_map = devm_kzalloc(dev, (n_tc + 1) * sizeof(s8),
+ GFP_KERNEL);
+ if (!queue_priority_map)
+ return -ENOMEM;
+
+ for (i = 0; i n_tc; i++) {
+ queue_priority_map[i][0] = i;
+ queue_priority_map[i][1] = i;
+ }
+ queue_priority_map[i][0] = -1;
+ queue_priority_map[i][1] = -1;
+
+ pdata-queue_priority_mapping = queue_priority_map;
+
+ pdata-default_queue = 0;
This is part is not really setting up from hardware (rather falling back
to some sane defaults for the DT case). Could you leave them in
edma_of_parse_dt()?
Not really since the number of tc is not know as early as edma_of_parse_dt(),
we used to a magic number of 3 in place for n_tc previously.
We are doing similar things as previously done in edma_of_parse_dt() but with
'correct' number of tc.
Okay. I did not notice the n_tc hardcoding. In that case to make this
function usable on non-DT case we will have to do something like:
/* Default to 1 if nothing passed */
if (!pdata-n_cc)
pdata-n_cc = 1;
if (!pdata-queue_priority_mapping) {
queue_priority_map = devm_kzalloc(...)
}
I was hoping we could avoid that.
@@ -1655,6 +1679,12 @@ static int edma_probe(struct platform_device *pdev)
if (IS_ERR(edmacc_regs_base[j]))
return PTR_ERR(edmacc_regs_base[j]);
+ if (node) {
+ /* Get eDMA3 configuration from IP */
+ ret = edma_setup_info_from_hw(dev, info[j]);
+ if (ret)
+ return ret;
No need to do this only for the DT case, I think. Also, once we get rid
of the edma_soc_info dependency, just pass edma_cc[] directly
edma_setup_info_from_hw(dev, j, edma_cc[j]);
Yes, let's do this for DT and not DT boot as well.
I will keep the queue_tc_map and queue_priority_map setup in there I think to
be done in case of DT boot.
Right.
I'll try to craft v3 as soon as I can.
Thanks.
Regards,
Sekhar
--
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 14/05/14 00:26, Tony Lindgren wrote:
+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;
+
+ 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);
+ }
+
+ /* lcd INI */
+ ddata-ini_gpio = sharp_ls_get_gpio_of(pdev-dev, 0, 0, enable);
+ if (PTR_ERR(ddata-ini_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
Hmm, the GPIOs are optional, but shouldn't we react somehow to real
errors? I guess we should do something like:
ddata-ini_gpio = sharp_ls_get_gpio_of(pdev-dev, 0, 0, enable);
if (IS_ERR(ddata-ini_gpio) {
int err = PTR_ERR(ddata-ini_gpio);
if (err == -EPROBE_DEFER || err != -ENOENT)
return err;
}
Tomi
signature.asc
Description: OpenPGP digital signature
Re: OMAP DSS: panel-dpi and enable gpios
On 12/05/14 20:58, Joachim Eastwood wrote:
Hello Tomi,
There seems to be a mismatch between your panel-dpi code and DT docs.
The docs state that enable-gpios is optinal but in panel-dpi.c you
have the following code
gpio = devm_gpiod_get(pdev-dev, enable);
if (IS_ERR(gpio)) {
dev_err(pdev-dev, failed to parse enable gpio\n);
return PTR_ERR(gpio);
} else {
gpiod_direction_output(gpio, 0);
ddata-enable_gpio = gpio;
}
Making probing fail on my DT since I don't use enable-gpios with
Would this work? Only compile tested.
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index dca6b10d1157..2ac38eaa4c8f 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -210,14 +210,19 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
struct gpio_desc *gpio;
gpio = devm_gpiod_get(pdev-dev, enable);
+
if (IS_ERR(gpio)) {
- dev_err(pdev-dev, failed to parse enable gpio\n);
- return PTR_ERR(gpio);
+ r = PTR_ERR(gpio);
+ if (r == -EPROBE_DEFER || r != -ENOENT)
+ return r;
+ else
+ gpio = NULL;
} else {
gpiod_direction_output(gpio, 0);
- ddata-enable_gpio = gpio;
}
+ ddata-enable_gpio = gpio;
+
ddata-backlight_gpio = -ENOENT;
r = of_get_display_timing(node, panel-timing, timing);
signature.asc
Description: OpenPGP digital signature
[PATCH] mmc: omap_hsmmc: use IS_ERR macro for error checking
Debounce clock is optional, use IS_ERR macro instead of NULL pointer check.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b7b755..521eec3 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1155,7 +1155,7 @@ static int omap_hsmmc_switch_opcond(struct
omap_hsmmc_host *host, int vdd)
/* Disable the clocks */
pm_runtime_put_sync(host-dev);
- if (host-dbclk)
+ if (!IS_ERR(host-dbclk))
clk_disable_unprepare(host-dbclk);
/* Turn the power off */
@@ -1166,7 +1166,7 @@ static int omap_hsmmc_switch_opcond(struct
omap_hsmmc_host *host, int vdd)
ret = mmc_slot(host).set_power(host-dev, host-slot_id, 1,
vdd);
pm_runtime_get_sync(host-dev);
- if (host-dbclk)
+ if (!IS_ERR(host-dbclk))
clk_prepare_enable(host-dbclk);
if (ret != 0)
@@ -1947,12 +1947,8 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
/*
* MMC can still work without debounce clock.
*/
- if (IS_ERR(host-dbclk)) {
- host-dbclk = NULL;
- } else if (clk_prepare_enable(host-dbclk) != 0) {
+ if (!IS_ERR(host-dbclk) clk_prepare_enable(host-dbclk))
dev_warn(mmc_dev(host-mmc), Failed to enable debounce clk\n);
- host-dbclk = NULL;
- }
/* Since we do only SG emulation, we can have as many segs
* as we want. */
@@ -2103,7 +2099,7 @@ err_irq:
dma_release_channel(host-rx_chan);
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
- if (host-dbclk)
+ if (!IS_ERR(host-dbclk))
clk_disable_unprepare(host-dbclk);
err1:
mmc_free_host(mmc);
@@ -2131,7 +2127,7 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
- if (host-dbclk)
+ if (!IS_ERR(host-dbclk))
clk_disable_unprepare(host-dbclk);
omap_hsmmc_gpio_free(host-pdata);
@@ -2175,7 +2171,7 @@ static int omap_hsmmc_suspend(struct device *dev)
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
}
- if (host-dbclk)
+ if (!IS_ERR(host-dbclk))
clk_disable_unprepare(host-dbclk);
pm_runtime_put_sync(host-dev);
@@ -2192,7 +2188,7 @@ static int omap_hsmmc_resume(struct device *dev)
pm_runtime_get_sync(host-dev);
- if (host-dbclk)
+ if (!IS_ERR(host-dbclk))
clk_prepare_enable(host-dbclk);
if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER))
--
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 v2 1/6] mmc: omap_hsmmc: use devm_clk_get
On Monday 12 May 2014 07:20 PM, Ulf Hansson wrote:
On 12 May 2014 15:33, Balaji T K balaj...@ti.com wrote:
On Monday 12 May 2014 02:03 PM, Ulf Hansson wrote:
On 9 May 2014 18:46, Balaji T K balaj...@ti.com wrote:
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;
You should use the IS_ERR macro, no need to reset dbclk to NULL.
Agreed, IS_ERR macro usage deserves patch on its own.
will create separate patch on top of this series.
Or you just update this patch, since it would touch there very same
piece of code. :-)
plus few more code additionally, since these are two different logical changes,
have sent a separate patch. But feel free to squash them if needed.
Thanks and Regards,
Balaji T K
--
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: RCU stall on panda
On 05/15/2014 05:05 PM, Daniel Lezcano wrote: After enable this patch, system maybe hang in idle. :( Hi Alex, do you mean even with this revert applied, the board hangs in idle ? yes. My board is panda ES. without this revert, it works. -- Thanks Alex -- 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 6/6] mmc: omap_hsmmc: split omap-dma header file
On Friday 09 May 2014 10:16 PM, Balaji T K wrote:
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
Hi Russell, Tony,
Since this patches touches omap dma header file,
can you provide your comments / ack if it looks ok ?
---
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 */
--
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: [PATCHv3 0/5] tsc2005 DT binding
On Sat, Apr 26, 2014 at 01:56:14AM +0200, Sebastian Reichel wrote: This adds device tree support for the tsc2005 touchscreen controller, which is currently only used by the Nokia N900 board. The patch does not update the reset pin handling for platform data based probe to avoid merge conflicts. The n900 platform code will be removed in the near future (3.16?) and the driver can be simplified once that has happened. Ping. It would be nice to see this patchset in 3.16, since its the last important hardware component missing for N900 DT boot. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v3 0/5] Add support for SW babble Control
George,
On Thu, May 15, 2014 at 1:28 AM, George Cherian george.cher...@ti.com wrote:
Hi Bin,
On 5/14/2014 10:13 PM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu binml...@gmail.com wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian george.cher...@ti.com
wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian george.cher...@ti.com
wrote:
Hi Daniel,
On 5/13/2014 6:44 PM, Daniel Mack wrote:
Hi George,
On 05/13/2014 02:57 PM, George Cherian wrote:
I never enabled the MUSB_BABBLE_SW_SESSION_CTRL in the
MUSB_BABBLE_CTL
reg.
can you try with the following patch.
diff --git a/drivers/usb/musb/musb_dsps.c
b/drivers/usb/musb/musb_dsps.c
index 1ae6681..1160cd1 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -477,8 +477,11 @@ static int dsps_musb_init(struct musb *musb)
* logic enabled.
*/
val = dsps_readb(musb-mregs, MUSB_BABBLE_CTL);
- if (val == MUSB_BABBLE_RCV_DISABLE)
+ if (val == MUSB_BABBLE_RCV_DISABLE) {
glue-sw_babble_enabled = true;
+ val |= MUSB_BABBLE_SW_SESSION_CTRL;
+ dsps_writeb(musb-mregs, MUSB_BABBLE_CTL, val);
+ }
ret = dsps_musb_dbg_init(musb, glue);
if (ret)
MUSB_BABBLE_STUCK_J still remains unset, so I get the same result as
without the patch: a full glue reset is conducted. Do I get you right
that you expect MUSB_BABBLE_STUCK_J to be set in babble conditions
when
MUSB_BABBLE_SW_SESSION_CTRL is set?
Basically, there are 2 types of babble conditions.
1) Transient babble condition - which could be recovered from without
an
IP
reset .
2) Babble condition - which could be recovered from only by doing an
IP
reset.
Looks like you are always hitting case 2 (Most times am also hitting
the
same).
Case 1 is really hard to reproduce. I don't have a reliable method as
of
now
to
reproduce this case consistently.
[ 19.672373] CAUTION: musb: Babble Interrupt Occurred
[ 19.66] musb_stage0_irq 789: unhandled DISCONNECT transition
(a_wait_bcon)
[ 19.685815] usb 1-1: USB disconnect, device number 3
[ 19.769720] musb-hdrc musb-hdrc.0.auto: babble: MUSB_BABBLE_CTL
value
44
[ 19.776765] musb-hdrc musb-hdrc.0.auto: STUCK_J is reset
I don't quite follow, especially as I lack documentation of the IP
core.
How do you test babble errors, is there any way to force them to
happen
reliably?
There is no 100% reliable method to force it to happen. Following is
I have a way to force babble happen reliably - shorting DP or DM to
VBUS. I opened the far-end plug of the USB cable, so I can easily
short DP or DM to VBUS.
Good to know that you have a reliable way to test babble condition.
Can you please do a quick test on 3.15.0-rc4 with the series applied?
In case of any assistance please do let me know.
Sure, but could you please re-send those patches to my corporate email
so that I can apply them from Thunderbird?
You don't have to resend the patches. Nishanth Menon showed me a way
to extract the patch from Gmail - Thanks Nishanth.
But which repo do you want to me test with? The first patch ([PATCH v2
1/5] usb: musb: core: Convert babble recover work to delayed work)
does not apply to v3.15-rc4 tag. the current musb_core.c does not have
the recovery work for musb. Please let me know what I missed.
Oops I missed to mention the same.
Please try on
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git master
The test is done. The babble always causes STUCK_J is reset,
MUSB_BABBLE_CTL is 0x44 or 0x4. MUSB reset happens.
Do you think when re-start happens the driver should print a message
on console saying re-start due to babble? It would help debug the
babble problems while the dynamic debug is off.
Thanks,
-Bin.
Thanks,
-Bin.
I read these linux-usb emails in Gmail, and am not aware of any easy
way to extract patches from Gmail.
BTY, I tested with TI 3.12.10 kernel, in which I guess the babble
handling is similar to this patch set. With TI3.12.10, MISC is always
0x64, so MUSB never restarts.
Thanks,
-Bin.
But the interesting thing is that with TI 3.2 kernel, shorting DP or
DM to VBUS causes MISC register to be 0x4, but the result is
completely opposite in TI 3.12.10 kernel, which cause MISC to be 0x64.
So in the 3.2 kernel, the babble handing resets the controller, but
the 3.12.10 does not.
Regards,
-Bin.
my setup ,
I have a HUB with 4 devices connected , which gives me a Babble
interrupt
on both connects and disconnects ( Not always though).
Anyway, the full glue layer solves this rare condition quite well for
me. Is there any downside of this?
Daniel
--
-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
Re: [PATCH] usb: dwc3: gadget: check link trb after free_slot is increased
Hi On Fri, May 16, 2014 at 05:57:57AM +0800, Zhuang Jin Can wrote: In ISOC transfers, when free_slot points to the last TRB (i.e. Link TRB), and all queued requests meet Missed Interval Isoc error, busy_slot points to trb0. busy_slot-trb0 trb1 ... free_slot-trb31(Link TRB) After end transfer and receiving the XferNotReady event, trb_left is caculated as 1 which is wrong, and no TRB will be primed to the endpoint. The root cause is free_slot is not increased the same way as busy_slot. When busy_slot is increased by one, it checks if points to a link TRB after increasement, but free_slot checks it before increasement. free_slot should behave the same as busy_slot to make the trb_left caculation correct. Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com Signed-off-by: Jiebing Li jiebing...@intel.com --- drivers/usb/dwc3/gadget.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 54da8c8..2ebe82b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -828,10 +828,6 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep, length, last ? last : , chain ? chain : ); - /* Skip the LINK-TRB on ISOC */ - if (((dep-free_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1) - usb_endpoint_xfer_isoc(dep-endpoint.desc)) - dep-free_slot++; trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK]; I have a feeling this has a negative side effect of letting us use the link TRB for data transfer... I mean, if we don't increment free_slot before accessing our trb_pool, we have no way to skip link trb on this access here. How did you find the bug ? do you have good instructions on how to reproduce it ? How did you test the patch and for how long ? cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/2] ARM: dts: Fix OMAP3 ISP functional clock configuration
On Monday 12 May 2014 18:06:10 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140512 16:17]: On Thursday 08 May 2014 13:57:15 Tomi Valkeinen wrote: On 21/04/14 13:41, Laurent Pinchart wrote: Hello, This patch set enables rate propagation from the OMAP3 ISP functional clock to the DPLL4 M5 clock. It copies Tomi Valkeinen's similar patch set for the OMAP DSS functional clock from the OMAP: OMAP3 DSS related clock patches patch series. Laurent Pinchart (2): ARM: dts: use ti,fixed-factor-clock for dpll4_m5x2_mul_ck ARM: dts: set 'ti,set-rate-parent' for dpll4_m5 path arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +- arch/arm/boot/dts/omap3xxx-clocks.dtsi | 7 --- 2 files changed, 5 insertions(+), 4 deletions(-) These look fine to me. Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Thank you. Tony, could you please pick the patches up for v3.16 ? I'd like to see acks from Tero on these two, or Tero queue them along with other clock dts clock changes. I'm fine with Tero queuing the patches in his tree. Tero, could they go in v3.16 ? -- Regards, Laurent Pinchart -- 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/2] ARM: dts: Fix OMAP3 ISP functional clock configuration
On 05/15/2014 06:53 PM, Laurent Pinchart wrote: On Monday 12 May 2014 18:06:10 Tony Lindgren wrote: * Laurent Pinchart laurent.pinch...@ideasonboard.com [140512 16:17]: On Thursday 08 May 2014 13:57:15 Tomi Valkeinen wrote: On 21/04/14 13:41, Laurent Pinchart wrote: Hello, This patch set enables rate propagation from the OMAP3 ISP functional clock to the DPLL4 M5 clock. It copies Tomi Valkeinen's similar patch set for the OMAP DSS functional clock from the OMAP: OMAP3 DSS related clock patches patch series. Laurent Pinchart (2): ARM: dts: use ti,fixed-factor-clock for dpll4_m5x2_mul_ck ARM: dts: set 'ti,set-rate-parent' for dpll4_m5 path arch/arm/boot/dts/omap36xx-clocks.dtsi | 2 +- arch/arm/boot/dts/omap3xxx-clocks.dtsi | 7 --- 2 files changed, 5 insertions(+), 4 deletions(-) These look fine to me. Acked-by: Tomi Valkeinen tomi.valkei...@ti.com Thank you. Tony, could you please pick the patches up for v3.16 ? I'd like to see acks from Tero on these two, or Tero queue them along with other clock dts clock changes. I'm fine with Tero queuing the patches in his tree. Tero, could they go in v3.16 ? Yeah, am fine with these, I'll queue these in my branch once I have those setup. -Tero -- 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: AM335x host only USB
Hi, On Thu, May 15, 2014 at 03:23:14PM +0800, 黃俊祺 wrote: Dear all, Is any update here? I'm looking forward for your reply, thanks. Steve 2013-11-21 19:07 GMT+08:00 Mark Jackson mpfj-l...@newflow.co.uk: We have a custom AM335x CPU board with a type A connector, which is intended to be run in host-only mode. Using Linus' latest git, I can compile a part-working kernel that can detect an (internal?) usb hub, but is unable to see any devices connected to it. Here's a snippet from my boot log:- Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.12.0-10713-gf9a173a-dirty pretty old kernel, friend. You know we can't really support you on such an old kernel, right ? In any case, try to backport commits: 943c13971c08ddeb06f4cb9dea1addb76f6b4423 2df6761e5eca9a810050a15062ae8abce1bbae41 and see what happens. I'm assuming you didn't ground ID pin, since you're using a standard A receptacle. I suggest hardwiring it to ground anyway. -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
Daniel,
On Wednesday 14 May 2014 05:18 PM, Santosh Shilimkar wrote:
On Wednesday 14 May 2014 04:02 PM, Daniel Lezcano wrote:
On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:
On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:
On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:
On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle /
omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.
Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} to avoid the issue. With this change, OMAP4 panda boards, the
mentioned
issues are getting fixed. We no longer loose interrupts which was the
cause
of the regression.
Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[ ... ]
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct
cpuidle_device *dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
[ ... ]
Shouldn't the broadcast timer to be setup with
CLOCK_EVT_NOTIFY_BROADCAST_ON also ?
Which is already taken care by __cpuidle_register_driver(). Note that setup
code
is still used from generic code...
Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle framework
won't setup the timer.
I see. I assumed it was taken care. So we might have setup the timer too.
static void __cpuidle_driver_init(struct cpuidle_driver *drv)
{
...
for (i = drv-state_count - 1; i = 0 ; i--) {
if (drv-states[i].flags CPUIDLE_FLAG_TIMER_STOP) {
May be you should start the bc timer in case 'CPUIDLE_FLAG_TIMER_STOP'
or 'CPUIDLE_FLAG_COUPLED'
drv-bctimer = 1;
break;
}
}
...
}
static int __cpuidle_register_driver(struct cpuidle_driver *drv)
{
...
if (drv-bctimer)
on_each_cpu_mask(drv-cpumask,
cpuidle_setup_broadcast_timer,
(void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);
...
}
So the broadcast timer does not operate with this revert. Moreover, I am not
sure reverting this patch is the right solution.
With above mentioned change, it should work. Other alternatives is OMAP4
driver does
its won registration where it can start the timer. The way it was before the
consolidation.
Ofcourse if you have better fix, then great.
What is your suggestion. We *must* fix the regression asap. I think
$subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
seems a good way forward.
Do let me know.
Regards,
Santosh
--
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: OMAP4: Fix the boot regression with CPU_IDLE enabled
On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:
Daniel,
On Wednesday 14 May 2014 05:18 PM, Santosh Shilimkar wrote:
On Wednesday 14 May 2014 04:02 PM, Daniel Lezcano wrote:
On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:
On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:
On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:
On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.
Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} to avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.
Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[ ... ]
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
[ ... ]
Shouldn't the broadcast timer to be setup with CLOCK_EVT_NOTIFY_BROADCAST_ON
also ?
Which is already taken care by __cpuidle_register_driver(). Note that setup code
is still used from generic code...
Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle framework
won't setup the timer.
I see. I assumed it was taken care. So we might have setup the timer too.
static void __cpuidle_driver_init(struct cpuidle_driver *drv)
{
...
for (i = drv-state_count - 1; i = 0 ; i--) {
if (drv-states[i].flags CPUIDLE_FLAG_TIMER_STOP) {
May be you should start the bc timer in case 'CPUIDLE_FLAG_TIMER_STOP'
or 'CPUIDLE_FLAG_COUPLED'
drv-bctimer = 1;
break;
}
}
...
}
static int __cpuidle_register_driver(struct cpuidle_driver *drv)
{
...
if (drv-bctimer)
on_each_cpu_mask(drv-cpumask,
cpuidle_setup_broadcast_timer,
(void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);
...
}
So the broadcast timer does not operate with this revert. Moreover, I am not
sure reverting this patch is the right solution.
With above mentioned change, it should work. Other alternatives is OMAP4 driver
does
its won registration where it can start the timer. The way it was before the
consolidation.
Ofcourse if you have better fix, then great.
What is your suggestion. We *must* fix the regression asap. I think
$subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
seems a good way forward.
Do let me know.
Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the
panda ES to hang.
I am not convinced the culprit is this code you are trying to revert.
I will try to reproduce the bug on my board.
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ 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] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote:
On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:
Daniel,
On Wednesday 14 May 2014 05:18 PM, Santosh Shilimkar wrote:
On Wednesday 14 May 2014 04:02 PM, Daniel Lezcano wrote:
On 05/14/2014 09:50 PM, Santosh Shilimkar wrote:
On Wednesday 14 May 2014 03:44 PM, Daniel Lezcano wrote:
On 05/13/2014 04:39 PM, Santosh Shilimkar wrote:
On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle /
omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to
common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug
..},
we loose interrupts which leads to issues like lock-up, hangs etc.
Patch reverts commit cb7094 {cpuidle / omap4 : use
CPUIDLE_FLAG_TIMER_STOP
flag} to avoid the issue. With this change, OMAP4 panda boards, the
mentioned
issues are getting fixed. We no longer loose interrupts which was the
cause
of the regression.
Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
[ ... ]
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct
cpuidle_device *dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
[ ... ]
Shouldn't the broadcast timer to be setup with
CLOCK_EVT_NOTIFY_BROADCAST_ON also ?
Which is already taken care by __cpuidle_register_driver(). Note that
setup code
is still used from generic code...
Nope, if the flag CPUIDLE_FLAG_TIMER_STOP is not set, the cpuidle
framework won't setup the timer.
I see. I assumed it was taken care. So we might have setup the timer too.
static void __cpuidle_driver_init(struct cpuidle_driver *drv)
{
...
for (i = drv-state_count - 1; i = 0 ; i--) {
if (drv-states[i].flags CPUIDLE_FLAG_TIMER_STOP) {
May be you should start the bc timer in case 'CPUIDLE_FLAG_TIMER_STOP'
or 'CPUIDLE_FLAG_COUPLED'
drv-bctimer = 1;
break;
}
}
...
}
static int __cpuidle_register_driver(struct cpuidle_driver *drv)
{
...
if (drv-bctimer)
on_each_cpu_mask(drv-cpumask,
cpuidle_setup_broadcast_timer,
(void *)CLOCK_EVT_NOTIFY_BROADCAST_ON, 1);
...
}
So the broadcast timer does not operate with this revert. Moreover, I am
not sure reverting this patch is the right solution.
With above mentioned change, it should work. Other alternatives is OMAP4
driver does
its won registration where it can start the timer. The way it was before the
consolidation.
Ofcourse if you have better fix, then great.
What is your suggestion. We *must* fix the regression asap. I think
$subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
seems a good way forward.
Do let me know.
Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the panda
ES to hang.
The hang is definitely due to the bctimer not started. As I said, I assumed it
was and
then you corrected saying it is under the flag.
I am not convinced the culprit is this code you are trying to revert.
fair enough. Thats why I said if you have an alternative fix thats great.
I will try to reproduce the bug on my board.
Sure...
--
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] OMAPDSS: move 'compatible' converter to omapdss driver
* Tomi Valkeinen tomi.valkei...@ti.com [140515 01:06]:
Move the panel/encoder driver compatible-string converter from
arch/arm/mach-omap2/display.c to omapdss driver. That is a more logical
place for it, as it's really an omapdss internal hack.
Thanks, maybe also consider just using the compatible flags
instead as discussed in the other thread. Anyways for moving
this out of mach-omap2:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 56 ---
drivers/video/fbdev/omap2/Makefile| 2 +-
drivers/video/fbdev/omap2/dss/Kconfig | 4 +
drivers/video/fbdev/omap2/dss/Makefile| 1 +
drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 112
++
5 files changed, 118 insertions(+), 57 deletions(-)
create mode 100644 drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 16d33d831287..519a20fc0432 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -555,65 +555,9 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
-/* list of 'compatible' nodes to convert to omapdss specific */
-static const char * const dss_compat_conv_list[] __initconst = {
- composite-connector,
- dvi-connector,
- hdmi-connector,
- panel-dpi,
- panel-dsi-cm,
- sony,acx565akm,
- svideo-connector,
- ti,tfp410,
- ti,tpd12s015,
-};
-
-/* prepend compatible string with omapdss, */
-static __init void omapdss_omapify_node(struct device_node *node,
- const char *compat)
-{
- char *new_compat;
- struct property *prop;
-
- new_compat = kasprintf(GFP_KERNEL, omapdss,%s, compat);
-
- prop = kzalloc(sizeof(*prop), GFP_KERNEL);
-
- if (!prop) {
- pr_err(omapdss_omapify_node: kzalloc failed\n);
- return;
- }
-
- prop-name = compatible;
- prop-value = new_compat;
- prop-length = strlen(new_compat) + 1;
-
- of_update_property(node, prop);
-}
-
-/*
- * As omapdss panel drivers are omapdss specific, but we want to define the
- * DT-data in generic manner, we convert the compatible strings of the panel
- * nodes from panel-foo to omapdss,panel-foo. This way we can have both
- * correct DT data and omapdss specific drivers.
- *
- * When we get generic panel drivers to the kernel, this will be removed.
- */
void __init omapdss_early_init_of(void)
{
- int i;
-
- for (i = 0; i ARRAY_SIZE(dss_compat_conv_list); ++i) {
- const char *compat = dss_compat_conv_list[i];
- struct device_node *node = NULL;
-
- while ((node = of_find_compatible_node(node, NULL, compat))) {
- if (!of_device_is_available(node))
- continue;
- omapdss_omapify_node(node, compat);
- }
- }
}
struct device_node * __init omapdss_find_dss_of_node(void)
diff --git a/drivers/video/fbdev/omap2/Makefile
b/drivers/video/fbdev/omap2/Makefile
index bf8127df8c71..f8745ec369cc 100644
--- a/drivers/video/fbdev/omap2/Makefile
+++ b/drivers/video/fbdev/omap2/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
-obj-$(CONFIG_OMAP2_DSS) += dss/
+obj-y += dss/
obj-y += displays-new/
obj-$(CONFIG_FB_OMAP2) += omapfb/
diff --git a/drivers/video/fbdev/omap2/dss/Kconfig
b/drivers/video/fbdev/omap2/dss/Kconfig
index dde4281663b1..a28f3a39ab1b 100644
--- a/drivers/video/fbdev/omap2/dss/Kconfig
+++ b/drivers/video/fbdev/omap2/dss/Kconfig
@@ -1,6 +1,10 @@
+config OMAP2_DSS_INIT
+ bool
+
menuconfig OMAP2_DSS
tristate OMAP2+ Display Subsystem support
select VIDEOMODE_HELPERS
+ select OMAP2_DSS_INIT
help
OMAP2+ Display Subsystem support.
diff --git a/drivers/video/fbdev/omap2/dss/Makefile
b/drivers/video/fbdev/omap2/dss/Makefile
index 8aec8bda27cc..3b79ad74f2e1 100644
--- a/drivers/video/fbdev/omap2/dss/Makefile
+++ b/drivers/video/fbdev/omap2/dss/Makefile
@@ -1,3 +1,4 @@
+obj-$(CONFIG_OMAP2_DSS_INIT) += omapdss-boot-init.o
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
diff --git a/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
new file mode 100644
index ..468f6eff370c
--- /dev/null
+++ b/drivers/video/fbdev/omap2/dss/omapdss-boot-init.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright (C) 2014 Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * This
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen tomi.valkei...@ti.com [140515 02:24]: On 14/05/14 19:02, Tony Lindgren wrote: The video paths of the panels and encoders are connected using the v4l2 style ports/endpoints. We can use those to see what display controller a panel is connected to, but only after the panel driver has already probed. We don't have control for the actual probing, as that happens with whatever the control bus is for the display component. OK. So with generic panels, you can just let the panels probe with the right compatible flag then and let the ports/endpoints registration to figure out if the panel is usable for the display controller in question. I'm not sure what you mean here. Do you mean with the future common display framework? There's no need to figure out anything there, as supposedly the .dts has been written correctly and the panel and the display controller work together. OK. Yes I meant for future use. If you mean with the current kernel, there's still nothing to figure out. We can have only single driver with a particular compatible string. And as our current drivers are omap specific, it makes sense to have their compatible string be something omap-ish. And if the .dts file connects the display controller and the panel, then they must be usable together. Yup. Well it seems at least the reset and enable pin standard from that binding can be kept. Only enable gpio there. But even that's vague. Do you turn on the power before or after setting the enable gpio? How long delay should be between the power and the gpio? Different panels have different rules for the power-up. Sure, it's a complex problem. But for the enable gpio.. Maybe the enable GPIO should be treated as a regulator? That would allow specifying first the source regulator startup delay, and then the panel has it's own startup delay. Well... I don't know. Sounds rather hacky to me. We have the option to have a specific driver for this panel, and that driver can handle all the delays and power-up sequences just right in a clean manner. I guess we could have a generic startup-latency property for the GPIOs. But I'm not really familiar with using extending current bindings, and making new bindings compatible with old ones. Can you explain why it'd be good to have the sharp panel bindings compatible with simple-panel? In what kind of scenario would it be used? Ideally the panel binding just describes the panel and it should not matter which display controller it is a child of. Yes, but that means the panel bindings need to have enough information so that all display controllers can use it. Simple-panel bindings do not have enough information. The simple-panel bindings do not have information about the video bus input, and it doesn't even have information about the resolution or bitdepth of the panel. Some of that you can hide into the panel driver based on the compatible flag. So why not already do something like this in the .dts files instead of the remapping: compatible = sharp,ls037v7dw01-omap-dss, sharp,ls037v7dw01; And drivers/video/fbdev/omap2/displays-new/panel-sharp-ls037v7dw01.c would only claim to be compatible with sharp,ls037v7dw01-omap-dss. Then when the common panel framework is available, you can stop parsing sharp,ls037v7dw01-omap-dss but the .dts files don't need to be changed and it's fine to keep sharp,ls037v7dw01-omap-dss in the .dts files. Hmm, I don't see how this relates to the simple-panel bindings. But you're right, having sharp,ls037v7dw01-omap-dss in the .dts is an alternative for the compatible-string conversion we do now. I guess it's a matter of taste, but I rather hide it inside the kernel, in an internal omapdss file, than pollute the .dts files with those compatible strings. Well it avoid you parsing through all the nodes during booting and leaves out the function to do remapping. And removes the need for maintaining a custom display mapping table. I'd say that's a pretty good list of advantages right there :) So I'm still asking, if we create sharp bindings that use the same properties as the simple-panel bindings, and define that sharp panel is compatible with simple-panel, what kind of scenario in practice would it be used in? Well with the above example, just by dss with sharp,ls037v7dw01-omap-dss until some other SoC notices it can use the GPIO parts of the panel code at least :) Would the scenario be some other OS, that doesn't have a driver for the sharp panel, but has a driver for the simple-panel? That would only work if the sharp panel hardware is setup so that only the enable gpio is needed, so that quite a narrow definition of compatible. That's where we can use the compatible flags and just avoid parsing the generic compatible flag unless some common framework is available. Hmm, sorry, I don't follow. My
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
* Tomi Valkeinen tomi.valkei...@ti.com [140515 01:42]: On 14/05/14 00:26, Tony Lindgren wrote: + /* lcd MO */ + ddata-mo_gpio = sharp_ls_get_gpio_of(pdev-dev, 0, 1, mode); + if (PTR_ERR(ddata-mo_gpio) == -EPROBE_DEFER) + return -EPROBE_DEFER; + + if (!IS_ERR(ddata-mo_gpio)) + if (gpiod_get_raw_value_cansleep(ddata-mo_gpio)) + ddata-flags |= SHARP_LS_QVGA; Shouldn't there be an explicit flag in the DT data for this? If the panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't have MO gpio, right? So something like: mode-gpios = 0 /* high, lcd MO */ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd UD */ vga-mode; /* MO hardwired high */ Yeah holes there are just fine. I figured let's keep the custom vga-mode property out of the way until we actually run into a panel that's not using a GPIO for mode. So far it seems that mode GPIO is there for the panels I've seen, just the scan direction pins seem to be hard wired on LDP. But then again, maybe I'm still having trouble locating all the GPIOs in the LDP schematics. Btw, the gpio.txt has each gpio inside : chipsel-gpios = gpio1 12 0, gpio1 13 0, 0, /* holes are permitted, means no GPIO 2 */ gpio2 2; Is that equivalent to having all gpios inside ? Yeah, just less braces. The number of elements for each entry is what matters and that's known by the GPIO parsing code. 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 [140515 06:08]:
On 14/05/14 00:26, Tony Lindgren wrote:
+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;
+
+ 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);
+ }
+
+ /* lcd INI */
+ ddata-ini_gpio = sharp_ls_get_gpio_of(pdev-dev, 0, 0, enable);
+ if (PTR_ERR(ddata-ini_gpio) == -EPROBE_DEFER)
+ return -EPROBE_DEFER;
Hmm, the GPIOs are optional, but shouldn't we react somehow to real
errors? I guess we should do something like:
ddata-ini_gpio = sharp_ls_get_gpio_of(pdev-dev, 0, 0, enable);
if (IS_ERR(ddata-ini_gpio) {
int err = PTR_ERR(ddata-ini_gpio);
if (err == -EPROBE_DEFER || err != -ENOENT)
return err;
}
Yeah that makes sense to me.
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: OMAP4: Fix the boot regression with CPU_IDLE enabled
On Thursday 15 May 2014 01:54 PM, Santosh Shilimkar wrote:
On Thursday 15 May 2014 01:50 PM, Daniel Lezcano wrote:
On 05/15/2014 07:03 PM, Santosh Shilimkar wrote:
[..]
With above mentioned change, it should work. Other alternatives is OMAP4
driver does
its won registration where it can start the timer. The way it was before
the
consolidation.
Ofcourse if you have better fix, then great.
What is your suggestion. We *must* fix the regression asap. I think
$subject patch with an update to bctimer start under CPUIDLE_FLAG_COUPLED
seems a good way forward.
Do let me know.
Did you see Alex Shi's email [cc'ed] ? Reverting this change makes the panda
ES to hang.
The hang is definitely due to the bctimer not started. As I said, I assumed
it was and
then you corrected saying it is under the flag.
I am not convinced the culprit is this code you are trying to revert.
fair enough. Thats why I said if you have an alternative fix thats great.
For record, below is updated patch with bctimer started which
was missed in earlier version. I haven't tested it though.
Alex,
Please give a try with your test-case and see if you still see the hang.
Am just curious about your issue and hence the request..
Regards,
Santosh
From bb3b82cc5645b83bedf1343d03cc956f27f6fc83 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 12 May 2014 17:37:59 -0400
Subject: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.
Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} and 54769d6 {cpuidle: OMAP4: remove timer broadcast initialization} to
avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.
Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..2498ab0 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -14,6 +14,7 @@
#include linux/cpuidle.h
#include linux/cpu_pm.h
#include linux/export.h
+#include linux/clockchips.h
#include asm/cpuidle.h
#include asm/proc-fns.h
@@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
{
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+ int cpu_id = smp_processor_id();
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET)
(cx-mpu_logic_state == PWRDM_POWER_OFF);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -172,6 +178,16 @@ fail:
return index;
}
+/*
+ * For each cpu, setup the broadcast timer because local timers
+ * stops for the states above C1.
+ */
+static void omap_setup_broadcast_timer(void *arg)
+{
+ int cpu = smp_processor_id();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu);
+}
+
static struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
.owner = THIS_MODULE,
@@ -189,8 +205,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
- .flags =
Re: RCU stall on panda
* Alex Shi alex@linaro.org [140515 06:27]: On 05/15/2014 05:05 PM, Daniel Lezcano wrote: After enable this patch, system maybe hang in idle. :( Hi Alex, do you mean even with this revert applied, the board hangs in idle ? yes. My board is panda ES. without this revert, it works. Care to specify what linux version you are testing against? Does it hang in idle always immediately on booting? Or does the serial console first hang with sysrq still working (ctrl-a h in minicom for help) with device eventually locking up hard? 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: RCU stall on panda
On Thursday 15 May 2014 02:32 PM, Tony Lindgren wrote:
* Alex Shi alex@linaro.org [140515 06:27]:
On 05/15/2014 05:05 PM, Daniel Lezcano wrote:
After enable this patch, system maybe hang in idle. :(
Hi Alex,
do you mean even with this revert applied, the board hangs in idle ?
yes.
My board is panda ES. without this revert, it works.
Care to specify what linux version you are testing against?
Does it hang in idle always immediately on booting?
Or does the serial console first hang with sysrq still
working (ctrl-a h in minicom for help) with device
eventually locking up hard?
I just posted an updated patch Alex on other thread.
Attaching here again for your reference. Please try
it out and see if the you still get a hang.
Regards,
Santosh
From bb3b82cc5645b83bedf1343d03cc956f27f6fc83 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Mon, 12 May 2014 17:37:59 -0400
Subject: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
On OMAP4 panda board, there have been several bug reports about boot
hang and lock-ups with CPU_IDLE enabled. The root cause of the issue
is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 :
use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common
code for right reasons but on OMAP4 which suffers from a nasty ROM code
bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..},
we loose interrupts which leads to issues like lock-up, hangs etc.
Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP
flag} and 54769d6 {cpuidle: OMAP4: remove timer broadcast initialization} to
avoid the issue. With this change, OMAP4 panda boards, the mentioned
issues are getting fixed. We no longer loose interrupts which was the cause
of the regression.
Cc: Roger Quadros rog...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Tony Lindgren t...@atomide.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Reported-tested-by: Roger Quadros rog...@ti.com
Reported-tested-by: Kevin Hilman khil...@linaro.org
Tested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/cpuidle44xx.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 01fc710..2498ab0 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -14,6 +14,7 @@
#include linux/cpuidle.h
#include linux/cpu_pm.h
#include linux/export.h
+#include linux/clockchips.h
#include asm/cpuidle.h
#include asm/proc-fns.h
@@ -83,6 +84,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
{
struct idle_statedata *cx = state_ptr + index;
u32 mpuss_can_lose_context = 0;
+ int cpu_id = smp_processor_id();
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -110,6 +112,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
mpuss_can_lose_context = (cx-mpu_state == PWRDM_POWER_RET)
(cx-mpu_logic_state == PWRDM_POWER_OFF);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, cpu_id);
+
/*
* Call idle CPU PM enter notifier chain so that
* VFP and per CPU interrupt context is saved.
@@ -165,6 +169,8 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
if (dev-cpu == 0 mpuss_can_lose_context)
cpu_cluster_pm_exit();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, cpu_id);
+
fail:
cpuidle_coupled_parallel_barrier(dev, abort_barrier);
cpu_done[dev-cpu] = false;
@@ -172,6 +178,16 @@ fail:
return index;
}
+/*
+ * For each cpu, setup the broadcast timer because local timers
+ * stops for the states above C1.
+ */
+static void omap_setup_broadcast_timer(void *arg)
+{
+ int cpu = smp_processor_id();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, cpu);
+}
+
static struct cpuidle_driver omap4_idle_driver = {
.name = omap4_idle,
.owner = THIS_MODULE,
@@ -189,8 +205,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C2 - CPU0 OFF + CPU1 OFF + MPU CSWR */
.exit_latency = 328 + 440,
.target_residency = 960,
- .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED
|
-CPUIDLE_FLAG_TIMER_STOP,
+ .flags = CPUIDLE_FLAG_TIME_VALID | CPUIDLE_FLAG_COUPLED,
.enter = omap_enter_idle_coupled,
.name = C2,
.desc = CPUx OFF, MPUSS CSWR,
@@ -199,8 +214,7 @@ static struct cpuidle_driver omap4_idle_driver = {
/* C3 - CPU0 OFF + CPU1 OFF + MPU OSWR */
[PATCH] ARM: OMAP: omap3stalker: remove two Kconfig macros
Checks for CONFIG_OMAP2_VENC_OUT_TYPE_SVIDEO and
CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE were added in v2.6.35. But the
related Kconfig symbols have never been added to the tree. Remove these
checks.
Initialize connector_type to OMAP_DSS_VENC_TYPE_COMPOSITE explicitly.
That's what's happening currently: OMAP_DSS_VENC_TYPE_COMPOSITE equals
zero and connector_type remains zero since both checks currently fail.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested.
arch/arm/mach-omap2/board-omap3stalker.c | 4
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 119efaf5808a..a2e035e0792a 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -121,11 +121,7 @@ static struct platform_device omap3stalker_tfp410_device =
{
static struct connector_atv_platform_data omap3stalker_tv_pdata = {
.name = tv,
.source = venc.0,
-#if defined(CONFIG_OMAP2_VENC_OUT_TYPE_SVIDEO)
- .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
-#elif defined(CONFIG_OMAP2_VENC_OUT_TYPE_COMPOSITE)
.connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
-#endif
.invert_polarity = false,
};
--
1.9.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: [PATCHv3 0/5] tsc2005 DT binding
Hi, On Thu, May 15, 2014 at 04:23:16PM +0200, Sebastian Reichel wrote: On Sat, Apr 26, 2014 at 01:56:14AM +0200, Sebastian Reichel wrote: This adds device tree support for the tsc2005 touchscreen controller, which is currently only used by the Nokia N900 board. The patch does not update the reset pin handling for platform data based probe to avoid merge conflicts. The n900 platform code will be removed in the near future (3.16?) and the driver can be simplified once that has happened. Ping. It would be nice to see this patchset in 3.16, since its the last important hardware component missing for N900 DT boot. FWIW, for all these patches feel free to add: Acked-by: Aaro Koskinen aaro.koski...@iki.fi Thanks for great work, A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: remove some dead code
A check for CONFIG_CBUS_TAHVO_USB was added in v2.6.17. The related
Kconfig symbol has never been part of the tree. Remove that check.
Replace the while (...) loop with a simple if (...) statement, while
we're at it.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, as usual.
A quick search across the history of the tree suggests CBUS_TAHVO_USB
was N770 related. Not that this matters much.
arch/arm/mach-omap1/pm.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index dbee729e3b6d..34b4c0044961 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -123,19 +123,8 @@ void omap1_pm_idle(void)
#warning Enable 32kHz OS timer in order to allow sleep states in idle
use_idlect1 = use_idlect1 ~(1 9);
#else
-
- while (enable_dyn_sleep) {
-
-#ifdef CONFIG_CBUS_TAHVO_USB
- extern int vbus_active;
- /* Clock requirements? */
- if (vbus_active)
- break;
-#endif
+ if (enable_dyn_sleep)
do_sleep = 1;
- break;
- }
-
#endif
#ifdef CONFIG_OMAP_DM_TIMER
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: SX1: remove check for CONFIG_SX1_OLD_FLASH
A check for CONFIG_SX1_OLD_FLASH was added in v2.6.24. But the related
Kconfig symbol was never part of the tree. So we can remove some dead
code.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Also untested.
arch/arm/mach-omap1/board-sx1.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/arch/arm/mach-omap1/board-sx1.c b/arch/arm/mach-omap1/board-sx1.c
index 0a8d3349149c..29e526235dc2 100644
--- a/arch/arm/mach-omap1/board-sx1.c
+++ b/arch/arm/mach-omap1/board-sx1.c
@@ -266,31 +266,6 @@ static struct physmap_flash_data sx1_flash_data = {
.nr_parts = ARRAY_SIZE(sx1_partitions),
};
-#ifdef CONFIG_SX1_OLD_FLASH
-/* MTD Intel StrataFlash - old flashes */
-static struct resource sx1_old_flash_resource[] = {
- [0] = {
- .start = OMAP_CS0_PHYS,/* Physical */
- .end= OMAP_CS0_PHYS + SZ_16M - 1,,
- .flags = IORESOURCE_MEM,
- },
- [1] = {
- .start = OMAP_CS1_PHYS,
- .end= OMAP_CS1_PHYS + SZ_8M - 1,
- .flags = IORESOURCE_MEM,
- },
-};
-
-static struct platform_device sx1_flash_device = {
- .name = physmap-flash,
- .id = 0,
- .dev= {
- .platform_data = sx1_flash_data,
- },
- .num_resources = 2,
- .resource = sx1_old_flash_resource,
-};
-#else
/* MTD Intel 4000 flash - new flashes */
static struct resource sx1_new_flash_resource = {
.start = OMAP_CS0_PHYS,
@@ -307,7 +282,6 @@ static struct platform_device sx1_flash_device = {
.num_resources = 1,
.resource = sx1_new_flash_resource,
};
-#endif
/*--- USB -*/
--
1.9.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] ARM: OMAP: remove some dead code
On Thu, May 15, 2014 at 09:16:21PM +0200, Paul Bolle wrote: A check for CONFIG_CBUS_TAHVO_USB was added in v2.6.17. The related Kconfig symbol has never been part of the tree. Remove that check. Replace the while (...) loop with a simple if (...) statement, while we're at it. Signed-off-by: Paul Bolle pebo...@tiscali.nl Acked-by: Aaro Koskinen aaro.koski...@iki.fi --- Untested, as usual. A quick search across the history of the tree suggests CBUS_TAHVO_USB was N770 related. Not that this matters much. Yes, Tahvo USB is only used on Nokia 770 (which is the correct name, not N770). The driver is nowadays behind TAHVO_USB, but like you said the old symbol was never part of the mainline so it's OK to delete it. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: AM3517EVM: remove check for CONFIG_PANEL_SHARP_LQ043T1DG01
The Kconfig symbol PANEL_SHARP_LQ043T1DG01 was removed in v2.6.38. The
check for CONFIG_PANEL_SHARP_LQ043T1DG01 and its MODULE variant has
evaluated to false ever since. Remove that check.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Untested, again.
arch/arm/mach-omap2/board-am3517evm.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 543d9a882de3..4f9383cecf76 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -262,12 +262,7 @@ static struct usbhs_phy_data phy_data[] __initdata = {
static struct usbhs_omap_platform_data usbhs_bdata __initdata = {
.port_mode[0] = OMAP_EHCI_PORT_MODE_PHY,
-#if defined(CONFIG_PANEL_SHARP_LQ043T1DG01) || \
- defined(CONFIG_PANEL_SHARP_LQ043T1DG01_MODULE)
- .port_mode[1] = OMAP_USBHS_PORT_MODE_UNUSED,
-#else
.port_mode[1] = OMAP_EHCI_PORT_MODE_PHY,
-#endif
};
#ifdef CONFIG_OMAP_MUX
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: replace checks for CONFIG_USB_GADGET_OMAP
Commit 193ab2a60700 (usb: gadget: allow multiple gadgets to be built)
apparently required that checks for CONFIG_USB_GADGET_OMAP would be
replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining
checks for CONFIG_USB_GADGET_OMAP, even though these checks have
basically been broken since v3.1.
Fixes: 193ab2a60700 (usb: gadget: allow multiple gadgets to be built)
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Also untested.
It seems efficient to also include the change to phy-isp1301-omap.c in
this patch (ie, not ship that as a separate patch).
arch/arm/mach-omap1/board-h2.c| 2 +-
arch/arm/mach-omap1/board-h3.c| 2 +-
arch/arm/mach-omap1/board-innovator.c | 2 +-
arch/arm/mach-omap1/board-osk.c | 2 +-
drivers/usb/phy/phy-isp1301-omap.c| 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 65d2acb31498..57092bc7f4f1 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -346,7 +346,7 @@ static struct omap_usb_config h2_usb_config __initdata = {
/* usb1 has a Mini-AB port and external isp1301 transceiver */
.otg= 2,
-#ifdef CONFIG_USB_GADGET_OMAP
+#ifdef CONFIG_USB_OMAP
.hmc_mode = 19, /* 0:host(off) 1:dev|otg 2:disabled */
/* .hmc_mode= 21,*/ /* 0:host(off) 1:dev(loopback) 2:host(loopback)
*/
#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index 816ecd13f81e..c828aacf469a 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -366,7 +366,7 @@ static struct omap_usb_config h3_usb_config __initdata = {
/* usb1 has a Mini-AB port and external isp1301 transceiver */
.otg= 2,
-#ifdef CONFIG_USB_GADGET_OMAP
+#ifdef CONFIG_USB_OMAP
.hmc_mode = 19, /* 0:host(off) 1:dev|otg 2:disabled */
#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
/* NONSTANDARD CABLE NEEDED (B-to-Mini-B) */
diff --git a/arch/arm/mach-omap1/board-innovator.c
b/arch/arm/mach-omap1/board-innovator.c
index bd5f02e9c354..1652ead0effa 100644
--- a/arch/arm/mach-omap1/board-innovator.c
+++ b/arch/arm/mach-omap1/board-innovator.c
@@ -312,7 +312,7 @@ static struct omap_usb_config h2_usb_config __initdata = {
/* usb1 has a Mini-AB port and external isp1301 transceiver */
.otg= 2,
-#ifdef CONFIG_USB_GADGET_OMAP
+#ifdef CONFIG_USB_OMAP
.hmc_mode = 19, /* 0:host(off) 1:dev|otg 2:disabled */
/* .hmc_mode= 21,*/ /* 0:host(off) 1:dev(loopback) 2:host(loopback)
*/
#elif defined(CONFIG_USB_OHCI_HCD) || defined(CONFIG_USB_OHCI_HCD_MODULE)
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index 3a0262156e93..70b1b282e5c2 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -283,7 +283,7 @@ static struct omap_usb_config osk_usb_config __initdata = {
* be used, with a NONSTANDARD gender-bending cable/dongle, as
* a peripheral.
*/
-#ifdef CONFIG_USB_GADGET_OMAP
+#ifdef CONFIG_USB_OMAP
.register_dev = 1,
.hmc_mode = 0,
#else
diff --git a/drivers/usb/phy/phy-isp1301-omap.c
b/drivers/usb/phy/phy-isp1301-omap.c
index 6e146d723b37..1ea6a0c30040 100644
--- a/drivers/usb/phy/phy-isp1301-omap.c
+++ b/drivers/usb/phy/phy-isp1301-omap.c
@@ -1295,7 +1295,7 @@ isp1301_set_host(struct usb_otg *otg, struct usb_bus
*host)
return isp1301_otg_enable(isp);
return 0;
-#elif !defined(CONFIG_USB_GADGET_OMAP)
+#elif !defined(CONFIG_USB_OMAP)
// FIXME update its refcount
otg-host = host;
--
1.9.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: OMAP DSS: panel-dpi and enable gpios
On 15 May 2014 15:18, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 12/05/14 20:58, Joachim Eastwood wrote:
Hello Tomi,
There seems to be a mismatch between your panel-dpi code and DT docs.
The docs state that enable-gpios is optinal but in panel-dpi.c you
have the following code
gpio = devm_gpiod_get(pdev-dev, enable);
if (IS_ERR(gpio)) {
dev_err(pdev-dev, failed to parse enable gpio\n);
return PTR_ERR(gpio);
} else {
gpiod_direction_output(gpio, 0);
ddata-enable_gpio = gpio;
}
Making probing fail on my DT since I don't use enable-gpios with
Would this work? Only compile tested.
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
index dca6b10d1157..2ac38eaa4c8f 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-dpi.c
@@ -210,14 +210,19 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
struct gpio_desc *gpio;
gpio = devm_gpiod_get(pdev-dev, enable);
+
if (IS_ERR(gpio)) {
- dev_err(pdev-dev, failed to parse enable gpio\n);
- return PTR_ERR(gpio);
+ r = PTR_ERR(gpio);
+ if (r == -EPROBE_DEFER || r != -ENOENT)
+ return r;
+ else
+ gpio = NULL;
} else {
gpiod_direction_output(gpio, 0);
- ddata-enable_gpio = gpio;
}
+ ddata-enable_gpio = gpio;
+
ddata-backlight_gpio = -ENOENT;
r = of_get_display_timing(node, panel-timing, timing);
Seems to do the trick here.
Display is showing Tux's on boot up again :)
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
DSS and HDMI kernel panic on OMAP4
Hello Tomi, I wanted to test my Variscite patches after Tony merged them into his 3.16 dt branch so created a base branch from Linus master and pull in Tony's 3.16 dt and your dss for-next branch. I discovered that booting with a HDMI monitor connected or plugging in one cause a kernel panic. See the log at: http://slexy.org/raw/s20xo68UPx Any idea what it could be? I also noted this in the boot log: [ 0.984527] omapdss_hdmi 58006000.encoder: can't request region for resource [mem 0x58006400-0x580073ff] I don't think I have seen this before. What I previously have tested have been Linus master + my Variscite patches and your panel-dpi dt + hdmi hpd patches cherry-picked. 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: DSS and HDMI kernel panic on OMAP4
On 15 May 2014 23:14, Joachim Eastwood manab...@gmail.com wrote: Hello Tomi, I wanted to test my Variscite patches after Tony merged them into his 3.16 dt branch so created a base branch from Linus master and pull in Tony's 3.16 dt and your dss for-next branch. I discovered that booting with a HDMI monitor connected or plugging in one cause a kernel panic. See the log at: http://slexy.org/raw/s20xo68UPx Any idea what it could be? I also noted this in the boot log: [ 0.984527] omapdss_hdmi 58006000.encoder: can't request region for resource [mem 0x58006400-0x580073ff] I don't think I have seen this before. What I previously have tested have been Linus master + my Variscite patches and your panel-dpi dt + hdmi hpd patches cherry-picked. Reverting OMAPDSS: HDMI: cleanup ioremaps 59b3d38a3691396783df108 from your for-next branch fixes the problem. 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
Hello From KM
Good Day, Please letâs talk and see if we can partner together to achieve our various future goals. Lets talk about real business deal. Regards, KM -- 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: OMAP: replace checks for CONFIG_USB_GADGET_OMAP
On Thu, May 15, 2014 at 10:55:45PM +0200, Paul Bolle wrote:
Commit 193ab2a60700 (usb: gadget: allow multiple gadgets to be built)
apparently required that checks for CONFIG_USB_GADGET_OMAP would be
replaced with checks for CONFIG_USB_OMAP. Do so now for the remaining
checks for CONFIG_USB_GADGET_OMAP, even though these checks have
basically been broken since v3.1.
Fixes: 193ab2a60700 (usb: gadget: allow multiple gadgets to be built)
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Also untested.
It seems efficient to also include the change to phy-isp1301-omap.c in
this patch (ie, not ship that as a separate patch).
arch/arm/mach-omap1/board-h2.c| 2 +-
arch/arm/mach-omap1/board-h3.c| 2 +-
arch/arm/mach-omap1/board-innovator.c | 2 +-
arch/arm/mach-omap1/board-osk.c | 2 +-
drivers/usb/phy/phy-isp1301-omap.c| 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index 65d2acb31498..57092bc7f4f1 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -346,7 +346,7 @@ static struct omap_usb_config h2_usb_config __initdata = {
/* usb1 has a Mini-AB port and external isp1301 transceiver */
.otg= 2,
-#ifdef CONFIG_USB_GADGET_OMAP
+#ifdef CONFIG_USB_OMAP
CONFIG_USB_OMAP is tristate, it might be better to use
IS_ENABLED(CONFIG_USB_OMAP) here. Likewise for the rest of the patch.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: OMAP4: Fix the boot regression with CPU_IDLE enabled
* Tony Lindgren t...@atomide.com [140514 16:32]: * Tony Lindgren t...@atomide.com [140514 13:57]: * Daniel Lezcano daniel.lezc...@linaro.org [140514 13:02]: So the broadcast timer does not operate with this revert. Moreover, I am not sure reverting this patch is the right solution. OK I'll hold on sending anything until there's some conclusion. Are you able to reproduce the problem with current Linux next? BTW, I'm also noticing now hangs on omap3 with my PM patches on v3.15-rc4 that seem similar to the panda cpuidle hang. The hangs on omap3 do not happen on my v3.14 based branch, so I'm wondering if there are some recent cpuidle regressions too in play? Looks like the omap3 idle hang is caused by commit 6ddeb6d84459 (dmaengine: omap-dma: move IRQ handling to omap-dma). This may not be related to omap4 cpu_idle hang, but it might. I'm trying to figure out if it's related to something like omap_dma_global_context_save and omap_dma_global_context_restore. Meanwhile, to test the DMA changes have an effect on the omap4 cpu_idle issue, you can try reverting the following two patches: aa4c5b962a7a dmaengine: omap-dma: more consolidation of CCR register setup 6ddeb6d84459 dmaengine: omap-dma: move IRQ handling to omap-dma 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: OMAP4: Fix the boot regression with CPU_IDLE enabled
On 05/16/2014 02:29 AM, Santosh Shilimkar wrote: Alex, Please give a try with your test-case and see if you still see the hang. Am just curious about your issue and hence the request.. there is no test case. I just patched your patches, then boot new kernel, system quickly to hang without any serial port oops, I am using pandaES/ubuntu. -- Thanks Alex -- 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: OMAP4: Fix the boot regression with CPU_IDLE enabled
* Tony Lindgren t...@atomide.com [140515 17:14]: * Tony Lindgren t...@atomide.com [140514 16:32]: * Tony Lindgren t...@atomide.com [140514 13:57]: * Daniel Lezcano daniel.lezc...@linaro.org [140514 13:02]: So the broadcast timer does not operate with this revert. Moreover, I am not sure reverting this patch is the right solution. OK I'll hold on sending anything until there's some conclusion. Are you able to reproduce the problem with current Linux next? BTW, I'm also noticing now hangs on omap3 with my PM patches on v3.15-rc4 that seem similar to the panda cpuidle hang. The hangs on omap3 do not happen on my v3.14 based branch, so I'm wondering if there are some recent cpuidle regressions too in play? Looks like the omap3 idle hang is caused by commit 6ddeb6d84459 (dmaengine: omap-dma: move IRQ handling to omap-dma). This may not be related to omap4 cpu_idle hang, but it might. I'm trying to figure out if it's related to something like omap_dma_global_context_save and omap_dma_global_context_restore. Meanwhile, to test the DMA changes have an effect on the omap4 cpu_idle issue, you can try reverting the following two patches: aa4c5b962a7a dmaengine: omap-dma: more consolidation of CCR register setup 6ddeb6d84459 dmaengine: omap-dma: move IRQ handling to omap-dma OK with the above reverted still seeing hangs on my panda es. So it seems the cpu_idle issue is different. 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 v2 0/5] Smart Card(SC) interface, TI USIM NxP SC phy driver
On 1/30/2014 6:35 PM, Greg KH wrote: On Thu, Jan 30, 2014 at 11:22:48AM +0530, Satish Patel wrote: On 1/20/2014 10:03 AM, Satish Patel wrote: Changes from v1: * RFC(v1) comments are fixed ** removed gpio_to_irq as GPIO controller process cell from DT and give it to DT node ** comments on documentation ** few other comments on null checks are resolved * BWT timing configuration is added to ti-usim driver v1 cover letter link# https://lkml.org/lkml/2014/1/6/250 Satish Patel (5): sc_phy:SmartCard(SC) PHY interface to SC controller misc: tda8026: Add NXP TDA8026 PHY driver char: ti-usim: Add driver for USIM module on AM43xx ARM: dts: AM43xx: DT entries added for ti-usim ARM: dts: AM43xx-epos-evm: DT entries for ti-usim and phy Documentation/devicetree/bindings/misc/tda8026.txt | 19 + .../devicetree/bindings/ti-usim/ti-usim.txt| 31 + Documentation/sc_phy.txt | 171 ++ arch/arm/boot/dts/am4372.dtsi | 10 + arch/arm/boot/dts/am43x-epos-evm.dts | 43 + drivers/char/Kconfig |7 + drivers/char/Makefile |1 + drivers/char/ti-usim-hw.h | 863 + drivers/char/ti-usim.c | 1859 drivers/misc/Kconfig |7 + drivers/misc/Makefile |1 + drivers/misc/tda8026.c | 1255 + include/linux/sc_phy.h | 132 ++ include/linux/ti-usim.h| 98 + 14 files changed, 4497 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/tda8026.txt create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt create mode 100644 Documentation/sc_phy.txt create mode 100644 drivers/char/ti-usim-hw.h create mode 100644 drivers/char/ti-usim.c create mode 100644 drivers/misc/tda8026.c create mode 100644 include/linux/sc_phy.h create mode 100644 include/linux/ti-usim.h Any comments on this patch series ? If not, Can you accept these patches for next merge window It's the middle of this merge window, and I can't accept any patches until after 3.14-rc1 is out, at which point I'll start to work on my patch backlog. Are these to be consider for next submission ? Or you want me to start review cycle one more time. thanks, greg k-h -- 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] usb: dwc3: gadget: check link trb after free_slot is increased
Hi On Thu, May 15, 2014 at 10:37:57AM -0500, Felipe Balbi wrote: Hi On Fri, May 16, 2014 at 05:57:57AM +0800, Zhuang Jin Can wrote: In ISOC transfers, when free_slot points to the last TRB (i.e. Link TRB), and all queued requests meet Missed Interval Isoc error, busy_slot points to trb0. busy_slot-trb0 trb1 ... free_slot-trb31(Link TRB) After end transfer and receiving the XferNotReady event, trb_left is caculated as 1 which is wrong, and no TRB will be primed to the endpoint. The root cause is free_slot is not increased the same way as busy_slot. When busy_slot is increased by one, it checks if points to a link TRB after increasement, but free_slot checks it before increasement. free_slot should behave the same as busy_slot to make the trb_left caculation correct. Signed-off-by: Zhuang Jin Can jin.can.zhu...@intel.com Signed-off-by: Jiebing Li jiebing...@intel.com --- drivers/usb/dwc3/gadget.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 54da8c8..2ebe82b 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -828,10 +828,6 @@ static void dwc3_prepare_one_trb(struct dwc3_ep *dep, length, last ? last : , chain ? chain : ); - /* Skip the LINK-TRB on ISOC */ - if (((dep-free_slot DWC3_TRB_MASK) == DWC3_TRB_NUM - 1) - usb_endpoint_xfer_isoc(dep-endpoint.desc)) - dep-free_slot++; trb = dep-trb_pool[dep-free_slot DWC3_TRB_MASK]; I have a feeling this has a negative side effect of letting us use the link TRB for data transfer... I mean, if we don't increment free_slot before accessing our trb_pool, we have no way to skip link trb on this access here. After every free_slot++ Link TRB is checked and increased if appropriate, this guarantees you next time access free_slot, it can't be a Link TRB. How did you find the bug ? do you have good instructions on how to reproduce it ? How did you test the patch and for how long ? The bug is reproduced on Android with f_audio_source.c enabled, which has an isoc-in endpoint keeps sending audio data to host in an interval of 1 ms. Normally, you need to run for 12+ hours to hit the issue. So I think you can just run some isoc transfers for a long time to reproduce it. To accelarte the reproducing, you can run some concurrent data transfer as well, so the possibility to meet missed interval error is larger. The patch is tested for basic functionality like enumeration, data transfers. For this bug, it was tested for 20+ hours. Thanks Jincan -- 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
[GIT PULL] ARM: OMAP2+: some hwmod data patches for v3.16
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit d1db0eea852497762cab43b905b879dfcd3b8987: Linux 3.15-rc3 (2014-04-27 19:29:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git for-v3.16/hwmod-a for you to fetch changes up to 433480707967187a74ced38bd38edba749998013: ARM: OMAP2+: hwmod: OMAP5 DSS hwmod data (2014-05-14 12:26:10 -0600) - First (and possibly last) set of hwmod data changes for v3.16. This set should clean up some obsolete OMAP4 hwmod data, and add OMAP5 DSS support. Basic build, boot, and PM logs are available here: http://www.pwsan.com/omap/testlogs/hwmod-a-v3.16/20140515210013/ - Archit Taneja (1): ARM: OMAP2+: hwmod: OMAP5 DSS hwmod data Peter Ujfalusi (1): ARM: omap4: hwmod_data: Clean up audio related structures (remove/merge them) arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 99 +- arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 283 + 2 files changed, 292 insertions(+), 90 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJTdZeVAAoJEMePsQ0LvSpLlPsP/32nvu4wLWKSRfHAZFSTO3cf MAPWwxsej9FfkOJN92Y/z6RVt8UNaIGmNTZgJr4tQMhvNuIxTM39jkl2NSB0ggJU NlQdJkgV6M5cGhKkAC3u7+Fz7/lxsr8ml2MpBzifHGVf9zZHGrNRhwMs3r34fVz0 pGu3XGQI/LBkASW5TLfEqWrYfYCBR1dsEVLlFuUfLc+DIvpFU7z07DM577BHLlzg 17KByqWHFW3dn15JSWYgOEFicYGnD5absjSXayAw5B9gjCKrNycPEk1Tm3FePX8r lH8cqHGJ7aiffhj2h/HkX8jUHKXNCyWkyEOzey59V8Rde1G5Rhm3dIxrlBldBS9e Wxa16MiqMktcVf4iUbuesTPEldtqkCc39zuiRwqQ6YRotFxmCPZlI+gNKkfmcqSD zRn+q+XoeNsh5Y9UekqfK4Cm1+NacLxmS8nxtjxaVPvkzLLX0lYubG8WRedg/501 7wCd/ubsRGeH+tSt49IItmoEYZgBysareZDxAL8oSX/7zjklaNJcR4k1uGZ8xDVU r9MNzxBl0a/wvCz6zGY8gdpy1hbCt9uM9iXH36nopG6oXOFayTQKZlv0g/xOlyzs gNy7ELwtVq7AVCnAPaeBy3kLbV5nOFWaTSR/jdaCfNx6oaGOVvFEzsDEU820Sd2G WXtp0giThLDS7xBdsQc/ =seX1 -END PGP SIGNATURE- -- 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
[GIT PULL] ARM: OMAP2+: some PRCM cleanup patches for v3.16
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5: Linux 3.15-rc1 (2014-04-13 14:18:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git for-v3.16/prcm-cleanup-a for you to fetch changes up to 70fcebf1965b66d73bd8ae7955bd663ab8012c56: ARM: OMAP4: PRCM: remove references to cm-regbits-44xx.h from PRCM core files (2014-05-15 22:35:10 -0600) - Some OMAP PRCM cleanup patches. These help prepare to convert the PRCM code into drivers. Basic build, boot, and PM test results are available here: http://www.pwsan.com/omap/testlogs/prcm-cleanup-v3.16/20140515213244/ - Tero Kristo (10): ARM: OMAP3: CM: remove a few OMAP34XX_CM_REGADDR defines ARM: OMAP2+: prcm: add omap_test_timeout to prcm-common.h ARM: OMAP2/3: CM: remove some external dependencies ARM: OMAP4: CM: use cm_base* in register address calculations ARM: OMAP2+: PRCM: cleanup some header includes ARM: OMAP2+: PRM: remove unnecessary cpu_is_XXX calls from prm_init / exit ARM: OMAP3/4: PRM: provide io chain reconfig function through irq setup ARM: OMAP3/OMAP4: PRM: add prm_features flags and add IO wakeup under it ARM: OMAP3/4: PRM: add support of late_init call to prm_ll_ops ARM: OMAP4: PRCM: remove references to cm-regbits-44xx.h from PRCM core files arch/arm/mach-omap2/clockdomain.h | 3 ++- arch/arm/mach-omap2/cm2xxx.c | 15 ++--- arch/arm/mach-omap2/cm33xx.h | 3 --- arch/arm/mach-omap2/cm3xxx.c | 25 -- arch/arm/mach-omap2/cm3xxx.h | 5 ++--- arch/arm/mach-omap2/cm44xx.c | 11 -- arch/arm/mach-omap2/cm_common.c| 2 +- arch/arm/mach-omap2/cminst44xx.c | 10 ++--- .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 1 + arch/arm/mach-omap2/powerdomain-common.c | 1 - arch/arm/mach-omap2/powerdomain.c | 1 + arch/arm/mach-omap2/powerdomain.h | 3 +-- arch/arm/mach-omap2/prcm-common.h | 24 + arch/arm/mach-omap2/prcm_mpu44xx.h | 1 - arch/arm/mach-omap2/prm.h | 10 + arch/arm/mach-omap2/prm2xxx.c | 13 +-- arch/arm/mach-omap2/prm2xxx_3xxx.c | 1 - arch/arm/mach-omap2/prm33xx.c | 1 - arch/arm/mach-omap2/prm3xxx.c | 20 - arch/arm/mach-omap2/prm44xx.c | 18 +++- arch/arm/mach-omap2/prm_common.c | 17 +-- 21 files changed, 93 insertions(+), 92 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJTdZg7AAoJEMePsQ0LvSpLvYYP/1QjKttZU9isMb2/WRR3tGay PKLkTu0OxHn7PznzdML+vpucD0ouQoD2wuDxpVrUQ1xzrk3yu2nAMm7hCWt3oPC0 jXzY/b6Ikf0SBk1HQ2ZqcBhYwhqAva8FwyZ6eUbztspnxPl5DIKWZ/0bEi1+3bLD Pp2kBX6bexssCOH26x+I4n3zVprlH9U1RgYhO/OaQ+rDaucOqTf30WyOxltCy1dI T/g2Q+obbTw8XGvP90T8Jognf6HgUpq8FuyX4WM6ypJ03bvlb/dNXUHj/MTcfUG0 MWz3I2LtgtYnhh4B3Rv77bVBCRPOyEBfDTXd+Lm3n3mc3dPgSrBoeZUoJNTVKeUG KJbm3qxjps5/iyGJyuif+opriey8IeQrAQhQSFB7oFw0Kl++L13Cm4HKCgx9QkBc TFNKK8N3oNHJPlgHWIDrJY/mdqmR7/kxFVy2bvxnfmSkxSyPXxWvGSe17GjIlTfN /jYOaygegbMI1Q6n+EuAhUY4v7qhDuzu75BnRpItxB5mzyYIYIV+f4tJlE6uDglh SEtFtRQnIjmNDQ72+70mYlgjy8VvdXc++JW1bjJyONMO5Ghb3CsrpeU+EThBw3Fu x+HJYNWDd0M3Jhhjjn3pfhkrpGbZNfCxM2QGczkZFWjhlsqdNwn8i/u1HMGb91Yr nm22ofeTTQrISphxouKg =fLlV -END PGP SIGNATURE- -- 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: DSS and HDMI kernel panic on OMAP4
On 16/05/14 00:26, Joachim Eastwood wrote: On 15 May 2014 23:14, Joachim Eastwood manab...@gmail.com wrote: Hello Tomi, I wanted to test my Variscite patches after Tony merged them into his 3.16 dt branch so created a base branch from Linus master and pull in Tony's 3.16 dt and your dss for-next branch. I discovered that booting with a HDMI monitor connected or plugging in one cause a kernel panic. See the log at: http://slexy.org/raw/s20xo68UPx Any idea what it could be? I also noted this in the boot log: [ 0.984527] omapdss_hdmi 58006000.encoder: can't request region for resource [mem 0x58006400-0x580073ff] I don't think I have seen this before. What I previously have tested have been Linus master + my Variscite patches and your panel-dpi dt + hdmi hpd patches cherry-picked. Reverting OMAPDSS: HDMI: cleanup ioremaps 59b3d38a3691396783df108 from your for-next branch fixes the problem. I think that's somehow HDMI audio enabled. I bet if you disable HDMI audio, the error goes away. If I cat /proc/iomem, I see: 58006000-58006fff : omap-hdmi-audio-dai 58006200-580062ff : pll 58006300-580063ff : phy Without sound support, I don't get the error and I see: 58006200-580062ff : pll 58006300-580063ff : phy 58006400-580073ff : core Reverting 59b3d38a3691396783df108e6afbba30656edccb helps, because before that patch the hdmi driver didn't actually reserve the regions. So, I don't really have any idea yet what's going on there, but the problem is somewhere around hdmi audio. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
On 15/05/14 21:25, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [140515 01:42]: On 14/05/14 00:26, Tony Lindgren wrote: + /* lcd MO */ + ddata-mo_gpio = sharp_ls_get_gpio_of(pdev-dev, 0, 1, mode); + if (PTR_ERR(ddata-mo_gpio) == -EPROBE_DEFER) + return -EPROBE_DEFER; + + if (!IS_ERR(ddata-mo_gpio)) + if (gpiod_get_raw_value_cansleep(ddata-mo_gpio)) + ddata-flags |= SHARP_LS_QVGA; Shouldn't there be an explicit flag in the DT data for this? If the panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't have MO gpio, right? So something like: mode-gpios = 0 /* high, lcd MO */ gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ gpio1 3 GPIO_ACTIVE_HIGH; /* gpio3, lcd UD */ vga-mode;/* MO hardwired high */ Yeah holes there are just fine. I figured let's keep the custom vga-mode property out of the way until we actually run into a panel that's not using a GPIO for mode. Ok, I'm fine with that, but in that case I think we have to use all the panels in the same mode, i.e. the driver either sets the MO gpio always low and uses VGA mode, or sets the MO always high and uses QVGA mode. In your omap3-evm.dts patch, you set the MO gpio ACTIVE_LOW in order to change the mode, even if it really should be ACTIVE_HIGH. But if you do that, and we later add the support to the panel driver to manage the MO gpio dynamically (i.e. the user can select VGA/QVGA at runtime), then the panel won't work as the driver uses wrong polarity for the pin. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
On 15/05/14 21:21, Tony Lindgren wrote: But you're right, having sharp,ls037v7dw01-omap-dss in the .dts is an alternative for the compatible-string conversion we do now. I guess it's a matter of taste, but I rather hide it inside the kernel, in an internal omapdss file, than pollute the .dts files with those compatible strings. Well it avoid you parsing through all the nodes during booting and leaves out the function to do remapping. And removes the need for maintaining a custom display mapping table. I'd say that's a pretty good list of advantages right there :) Yep... I don't know. Maybe I'm being too careful about doing wrong things with .dts. I just like it more if any hacks are in kernel code, which I can remove without anyone noticing. Anyway, we already have board.dts files using the non-omapified compatible strings in the mainline, so if I would now add the omapified compatible strings to .dts files, those old board.dts files would break. So I guess the choice has already been made. Tomi signature.asc Description: OpenPGP digital signature
