Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x
Hi, On 18/03/15 11:06, Jyri Sarha wrote: I think the patches 1-5 are ready for merging. See the details below. I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules. After doing that and waiting a few secs: # ./s-bbb.sh [ 15.237139] sysrq: SysRq : Changing Loglevel [ 15.241646] sysrq: Loglevel set to 9 [ 15.319762] [drm] Initialized drm 1.1.0 20060810 [ 15.588122] tda998x 0-0070: found TDA19988 [ 15.594824] tilcdc 4830e000.lcdc: bound 0-0070 (ops tda998x_ops [tda998x]) [ 15.602034] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 15.609011] [drm] No driver support for vblank timestamp query. [ 15.700798] tilcdc 4830e000.lcdc: fb0: frame buffer device [ 15.706757] tilcdc 4830e000.lcdc: registered panic notifier [ 15.712659] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0 # # [ 25.789364] [ cut here ] [ 25.794315] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 25.805999] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 25.812325] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g5fbf26ebaf12 #7 [ 25.820893] Hardware name: Generic AM33XX (Flattened Device Tree) [ 25.827359] Workqueue: events output_poll_execute [drm_kms_helper] [ 25.833819] Backtrace: [ 25.836439] [c0013550] (dump_backtrace) from [c0013764] (show_stack+0x18/0x1c) [ 25.844380] r6:c09d4228 r5:c09d4228 r4: r3:dd3604c0 [ 25.850338] [c001374c] (show_stack) from [c066bbc0] (dump_stack+0xa4/0xd4) [ 25.857927] [c066bb1c] (dump_stack) from [c0044d28] (warn_slowpath_common+0x84/0xc0) [ 25.866401] r6:010d r5:bf0a010c r4: r3:dd3604c0 [ 25.872348] [c0044ca4] (warn_slowpath_common) from [c0044e08] (warn_slowpath_null+0x24/0x2c) [ 25.881543] r8:dd50 r7:000f r6:bf0a25f0 r5:dd6b1400 r4:dd4e6800 [ 25.888617] [c0044de4] (warn_slowpath_null) from [bf0a010c] (tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]) [ 25.898849] [bf09fb20] (tilcdc_crtc_mode_set [tilcdc]) from [bf06d874] (drm_crtc_helper_set_mode+0x2b0/0x4f0 [drm_kms_helper]) [ 25.911132] r10:dd4e6bf0 r9:dd4e6800 r8:dd4e2e80 r7:dd6b1400 r6:0001 r5:dd50 [ 25.919372] r4:bf09fb20 [ 25.922061] [bf06d5c4] (drm_crtc_helper_set_mode [drm_kms_helper]) from [bf06e450] (drm_crtc_helper_set_config+0x768/0x9c8 [drm_kms_helper]) [ 25.935612] r10: r9:dd73d980 r8:dd4e6bf0 r7:bf031808 r6:dd4e6be4 r5:dd4e6bd8 [ 25.943827] r4:dd50 [ 25.946758] [bf06dce8] (drm_crtc_helper_set_config [drm_kms_helper]) from [bf00dcfc] (drm_mode_set_config_internal+0x6c/0xf4 [drm]) [ 25.959518] r10:0001 r9: r8:dd4b4b40 r7:dd50 r6:0001 r5:0028 [ 25.967767] r4:dd4b46c0 [ 25.970558] [bf00dc90] (drm_mode_set_config_internal [drm]) from [bf077a88] (restore_fbdev_mode+0xe0/0x100 [drm_kms_helper]) [ 25.982672] r7:dd73d980 r6:0001 r5:0028 r4: [ 25.988698] [bf0779a8] (restore_fbdev_mode [drm_kms_helper]) from [bf0799cc] (drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x64 [drm_kms_helper]) [ 26.002884] r9:dd4e6be4 r8:bf031808 r7:dd4e6800 r6:dd4e6800 r5:dd4b46c0 r4:dd4b4b40 [ 26.011104] [bf0799a8] (drm_fb_helper_restore_fbdev_mode_unlocked [drm_kms_helper]) from [bf079a2c] (drm_fb_helper_set_par+0x20/0x3c [drm_kms_helper]) [ 26.025562] r6:dd4e6800 r5:dd4b46c0 r4: r3: [ 26.031556] [bf079a0c] (drm_fb_helper_set_par [drm_kms_helper]) from [bf079968] (drm_fb_helper_hotplug_event+0x90/0xd0 [drm_kms_helper]) [ 26.044753] r4:dd4b4b40 r3: [ 26.048557] [bf0798d8] (drm_fb_helper_hotplug_event [drm_kms_helper]) from [bf07a7c4] (drm_fbdev_cma_hotplug_event+0x18/0x1c [drm_kms_helper]) [ 26.062289] r7:dd4e6a40 r6:0001 r5:dd4e6c38 r4:dd4e6800 [ 26.068300] [bf07a7ac] (drm_fbdev_cma_hotplug_event [drm_kms_helper]) from [bf0a217c] (tilcdc_fb_output_poll_changed+0x18/0x1c [tilcdc]) [ 26.081521] [bf0a2164] (tilcdc_fb_output_poll_changed [tilcdc]) from [bf06f388] (drm_kms_helper_hotplug_event+0x2c/0x30 [drm_kms_helper]) [ 26.094840] [bf06f35c] (drm_kms_helper_hotplug_event [drm_kms_helper]) from [bf06f448] (output_poll_execute+0x6c/0x18c [drm_kms_helper]) [ 26.108027] r4:dd4e6bd8 r3: [ 26.111809] [bf06f3dc] (output_poll_execute [drm_kms_helper]) from [c005c704] (process_one_work+0x1e8/0x560) [ 26.122456] r10:dfa1b700 r9: r8:c0a0c0b8 r7:dd51deb0 r6:dfa157c0 r5:dd4b4d40 [ 26.130696] r4:dd4e6c38 [ 26.133353] [c005c51c] (process_one_work) from [c005d42c] (worker_thread+0x160/0x4c4) [ 26.141914] r10:dfa157c0 r9:0008 r8:dd4b4d58 r7:dd4b4d40 r6:c005d304 r5:dfa157f0 [ 26.150153] r4:dfa157c0 [ 26.152812] [c005d2cc] (worker_thread) from [c0061e38] (kthread+0xf0/0x110) [ 26.160465] r10: r9: r8: r7:c005d2cc r6:dd4b4d40 r5:dd509cc0 [ 26.168704] r4: [ 26.171362] [c0061d48] (kthread) from [c000f6d0]
Re: [PATCH] EDMA: TI: fixed memory leak when terminating running transfers
On 03/23/2015 05:00 PM, Petr Kulhavy wrote:
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan-edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.
It is another question if it is really correct to remove the the currently
running desc from the issued list in edma_execute().
Based on what I have seen some drivers using virt-dma does this while others
not.
Russel, do you have any advice on this?
Will this work for you to fix the leak:
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..ea8544481245 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -162,7 +162,6 @@ static void edma_execute(struct edma_chan *echan)
echan-edesc = NULL;
return;
}
- list_del(vdesc-node);
echan-edesc = to_edma_desc(vdesc-tx);
}
@@ -760,6 +759,7 @@ static void edma_callback(unsigned ch_num, u16 ch_status,
void *data)
dev_dbg(dev, Transfer complete, stopping
channel %d\n, ch_num);
edesc-residue = 0;
edma_stop(echan-ch_num);
+ list_del(edesc-vdesc.node);
vchan_cookie_complete(edesc-vdesc);
edma_execute(echan);
} else {
This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the
SD
card wasted the device 128MB RAM within a couple of days.
Signed-off-by: Petr Kulhavy p...@barix.com
---
drivers/dma/edma.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 276157f..1465610 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -260,6 +260,14 @@ static int edma_terminate_all(struct dma_chan *chan)
*/
if (echan-edesc) {
int cyclic = echan-edesc-cyclic;
+
+ /*
+ * free the running request descriptor
+ * since it is on none of the vchan lists
+ * desc_submitted, desc_issued, desc_completed
+ */
+ kfree(echan-edesc);
If we do this I would prefer to have:
edma_desc_free(echan-edesc-vdesc);
+
echan-edesc = NULL;
edma_stop(echan-ch_num);
/* Move the cyclic channel back to default queue */
--
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] ARM: omap2plus_defconfig: Enable EXTCON_USB_GPIO
On 12:19-20150324, Roger Quadros wrote: We need to enable EXTCON_USB_GPIO_USB and not EXTCON_GPIO_USB. Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB) Reported-by: Nishant Menon n...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/configs/omap2plus_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 04b4c8e..daf9412 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -391,7 +391,7 @@ CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXTCON=m -CONFIG_EXTCON_GPIO=m +CONFIG_EXTCON_USB_GPIO=m CONFIG_EXTCON_PALMAS=m CONFIG_TI_EMIF=m CONFIG_PWM=y -- 2.1.0 Yep and it finally works! Yipiee!! http://pastebin.ubuntu.com/10669565/ Acked-and-Tested-by: Nishanth Menon n...@ti.com -- 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: Serious memory leak in TI EDMA driver (drivers/dma/edma.c)
On 03/23/2015 05:45 PM, Petr Kulhavy wrote:
Hi Peter,
I've just posted a patch to the community, you should have received another
email from me just a few minutes ago.
Basically there should be a kfree in terminate_all() just before echan-edesc
is set to NULL.
The reason is that at that point the edesc is in none of the vchan lists
(edma_execute() removes it from the issued list)
and vchan_get_all_descriptors() doesn't find it.
And this is the main issue in my view. The desc should be in one of the lists
IMHO.
With the extra kfree the mem leak is not seen any more.
It's a good question why terminate_all is called before the transfer finished,
but I thought it could be called at any time?
I'm also not sure if the echan-edesc shouldn't be free also in
edma_execute(), could you please check that? :
static void edma_execute(struct edma_chan *echan)
{
struct virt_dma_desc *vdesc;
struct edma_desc *edesc;
struct device *dev = echan-vchan.chan.device-dev;
int i, j, left, nslots;
/* If either we processed all psets or we're still not started */
if (!echan-edesc ||
echan-edesc-pset_nr == echan-edesc-processed) {
/* Get next vdesc */
vdesc = vchan_next_desc(echan-vchan);
if (!vdesc) {
dev_dbg(dev, Setting edesc 0x%p to NULL\n,echan-edesc);
echan-edesc = NULL;
#warning possible memory leak here ?
Yes, it would be, but in fact this will never happen since the edma_execute()
will not be called when echan-edesc is not NULL _and_ (echan-edesc-pset_nr
== echan-edesc-processed).
if we have echan-edesc, we are in a middle of transfer, moving from one batch
of sg to another batch.
I do have cleanup patches for this part to clarify the situation.
return;
}
list_del(vdesc-node);// at this point node was in issued
echan-edesc = to_edma_desc(vdesc-tx);
}
I'll post another patch for the wrong type in edma_alloc_chan_resources()
Regards
Petr
On 23.03.2015 16:28, Peter Ujfalusi wrote:
On 03/20/2015 11:53 PM, Petr Kulhavy wrote:
Hi Peter,
yes, that is one of the differences to the EVM that the SD card is on
MMCSD1.
This is due to the pin multiplexer and other peripherals we're using.
Your patch is correct, however the edma_callback() is using the channel
number parameter for debug messages only. For the actual work echan-ch_num
is
used. BTW is that correct? Could there be a mismatch between the
echan-ch_num
and the ch_num parameter?
Something else seems to be odd in edma_alloc_chan_resources():
/* Alloc channel resources */
static int edma_alloc_chan_resources(struct dma_chan *chan)
{
struct edma_chan *echan = to_edma_chan(chan);
struct device *dev = chan-device-dev;
int ret;
int a_ch_num;
LIST_HEAD(descs);
a_ch_num = edma_alloc_channel(echan-ch_num, edma_callback,
chan, EVENTQ_DEFAULT);
Hah, yes this is wrong but worked so far fine because:
struct edma_chan {
struct virt_dma_chanvchan;
...
};
struct virt_dma_chan {
struct dma_chanchan;
...
};
so edma_chan == edma_chan.vchan.chan;
But this is not why you see the leak.
What I did on my board is that I have swapped in SW the cc0 and cc1, now mmc0
is on cc1 from the sw point of view, but still can not reproduce the issue.
The third parameter to edma_alloc_channel() should be echan, not chan, since
the edma_callback() interprets the callback data parameter as struct
edma_chan *.
Let me know if you find something or if you have an advice for more debug.
From the log I would go and see what happens in the
vchan_get_all_descriptors() and vchan_dma_desc_free_list(), is it so that at
terminate_all time the list we got is empty? But why it is?
It seams you got the terminate_all call before the transfer finished, this is
also interesting. I'll look at at this more deeply.
What I see is that at terminate_all we clear the echan-edesc and for some
reason the vchan code will not free the desc. Later the completion interrupt
comes, but since the echan-edesc is NULL we do nothing. This causes the
leak.
The question to all of this why and how to reproduce it?
--
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 2/2] EDMA: TI: fixed wrongly initialized data parameter to the edma callback
On 03/23/2015 10:35 PM, Petr Kulhavy wrote:
The data parameter passed indirectly to the edma_callback() should be
edma_chan and not the dma_chan.
This bug was so far harmless since the offset of struct dma_chan within struct
edma_chan is 0. However as soon as someone changes struct edma_chan this would
cause troubles.
Good catch. This seams to be in the code since the first commit ;)
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Petr Kulhavy p...@barix.com
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 1465610..4c8208b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -813,7 +813,7 @@ static int edma_alloc_chan_resources(struct dma_chan
*chan)
LIST_HEAD(descs);
a_ch_num = edma_alloc_channel(echan-ch_num, edma_callback,
- chan, EVENTQ_DEFAULT);
+ echan, EVENTQ_DEFAULT);
if (a_ch_num 0) {
ret = -ENODEV;
--
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 v7 0/6] wlcore: add device-tree support
Hi Eliad, On 03/18/2015 06:38 PM, Eliad Peller wrote: Add device-tree support to the wlcore (wl12xx/wl18xx) driver. Update the current users to use the bindings instead of pdata-quirks. Finally, remove the deprecated wl12xx_platform_data struct (along with the da850 board file code that still uses it) Tested-by: Nikita Kiryanov nik...@compulab.co.il Tested on am437x-gp-evm with WL1835MODCOM8B -- Regards, Nikita Kiryanov -- 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] tty/serial: omap: fix !wakeirq message
On Mon, Mar 23, 2015 at 05:38:44PM -0500, Doug Kehn wrote: When wakeirq is not used/enabled, no wakeirq for uart0 is output for all TTY as the log message is generated before the port line is initialized. [0.802656] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.811700] omap_uart 44e09000.serial: no wakeirq for uart0 [0.812379] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88, base_baud = 300) is a OMAP UART0 [1.503622] console [ttyO0] enabled [1.509836] omap_uart 48022000.serial: no wakeirq for uart0 [1.516118] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89, base_baud = 300) is a OMAP UART1 [1.527711] omap_uart 48024000.serial: no wakeirq for uart0 [1.533881] 48024000.serial: ttyO2 at MMIO 0x48024000 (irq = 90, base_baud = 300) is a OMAP UART2 [1.545324] omap_uart 481a6000.serial: no wakeirq for uart0 [1.551410] 481a6000.serial: ttyO3 at MMIO 0x481a6000 (irq = 60, base_baud = 300) is a OMAP UART3 [1.562946] omap_uart 481a8000.serial: no wakeirq for uart0 [1.569036] 481a8000.serial: ttyO4 at MMIO 0x481a8000 (irq = 61, base_baud = 300) is a OMAP UART4 Fix by moving wakeirq check and dev_info() call to after port line initialization and validation. Patch is against 3.14.36. That's really old, please make this against a modern kernel, like the 4.0-rc series. 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
[PATCH] ARM: omap2plus_defconfig: Enable EXTCON_USB_GPIO
We need to enable EXTCON_USB_GPIO_USB and not EXTCON_GPIO_USB. Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB) Reported-by: Nishant Menon n...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/configs/omap2plus_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 04b4c8e..daf9412 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -391,7 +391,7 @@ CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXTCON=m -CONFIG_EXTCON_GPIO=m +CONFIG_EXTCON_USB_GPIO=m CONFIG_EXTCON_PALMAS=m CONFIG_TI_EMIF=m CONFIG_PWM=y -- 2.1.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: [rtc-linux] [PATCH] rtc: OMAP: Add external 32k clock feature
On Tue, 3 Mar 2015 15:12:02 +0530 Keerthy j-keer...@ti.com wrote:
Add external 32k clock feature. The internal clock will be gated during
suspend.
Hence make use of the external 32k clock so that rtc is functional accross
suspend/resume.
...
@@ -446,6 +449,7 @@ static const struct omap_rtc_device_type
omap_rtc_default_type = {
static const struct omap_rtc_device_type omap_rtc_am3352_type = {
.has_32kclk_en = true,
+ .has_osc_ext_32k = true,
.has_kicker = true,
.has_irqwakeen = true,
.has_pmic_mode = true,
@@ -543,7 +547,16 @@ static int __init omap_rtc_probe(struct platform_device
*pdev)
if (rtc-type-has_32kclk_en) {
reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
rtc_writel(rtc, OMAP_RTC_OSC_REG,
- reg | OMAP_RTC_OSC_32KCLK_EN);
+reg | OMAP_RTC_OSC_32KCLK_EN);
+ }
+
+ /* Enable External clock as the source */
+
+ if (rtc-type-has_osc_ext_32k) {
+ rtc_writel(rtc, OMAP_RTC_OSC_REG,
+(OMAP_RTC_OSC_EXT_32K |
+rtc_read(rtc, OMAP_RTC_OSC_REG))
+(~OMAP_RTC_OSC_OSC32K_GZ));
}
How do we know that all systems have this external clock and that it
works OK?
--
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: [PATCHv2] ti-soc-thermal: request temperature periodically if hw can't do that itself
On Tue 2015-03-24 12:30:34, Eduardo Valentin wrote: On Sun, Jan 18, 2015 at 09:24:47PM +0100, Pavel Machek wrote: When periodic mode is not enabled, it is neccessary to force reads. Signed-off-by: Pavel Machek pa...@ucw.cz This is a malformed patch. here is patch output (or git am) patching file drivers/thermal/ti-soc-thermal/ti-bandgap.c patch: malformed patch at line 68: (english) http://www.livejournal.com/~pavelmachek Sorry about that. You should have fixed [PATCHv3] in your inbox now. I would really recommend you to use git to send your patches to avoid such problems. Can you please resend this patch in its proper format? Done. I verified that the other 2 patches are ok, by applying them in following order: Subject: [PATCHv3] ti-soc-thermal: request temperature periodically if hw can't do that itself Date: Sun, 18 Jan 2015 21:20:51 +0100 From: Pavel Machek pa...@ucw.cz Subject: [PATCHv2] ti-soc-thermal: implement eocz bit to make driver useful on omap3 Date: Sun, 18 Jan 2015 21:17:10 +0100 From: Pavel Machek pa...@ucw.cz Subject: [PATCHv2] cleanup ti-soc-thermal Best regards and thanks for patience, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3] ti-soc-thermal: request temperature periodically if hw can't do that itself
When periodic mode is not enabled, it is neccessary to force reads.
Signed-off-by: Pavel Machek pa...@ucw.cz
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 62a5d44..ec533e7 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -43,6 +43,8 @@
#include ti-bandgap.h
+static int ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id);
+
/*** Helper functions to access registers and their bitfields ***/
/**
@@ -852,6 +854,12 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp,
int id,
if (ret)
return ret;
+ if (!TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
+ ret = ti_bandgap_force_single_read(bgp, id);
+ if (ret)
+ return ret;
+ }
+
spin_lock(bgp-lock);
temp = ti_bandgap_read_temp(bgp, id);
spin_unlock(bgp-lock);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 06/10] arm/dts: dra7.dtsi: add DSS support
DRA7xxx contains a very similar DSS to OMAP5. The main differences are:
* no DSI or RFBI support.
* 1 or 2 dedicated video PLLs.
* need to do additional configuration to the DRA7 CONTROL module.
DRA72xx has only one video PLL, and DRA74xx has two.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7.dtsi | 38 ++
arch/arm/boot/dts/dra72x.dtsi | 11 +++
arch/arm/boot/dts/dra74x.dtsi | 15 +++
3 files changed, 64 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 8e50ca3fc102..312ede660b23 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1445,6 +1445,44 @@
clocks = sys_clkin1;
status = disabled;
};
+
+ dss: dss@5800 {
+ compatible = ti,dra7-dss;
+ /* 'reg' defined in dra72x.dtsi and dra74x.dtsi */
+ /* 'clocks' defined in dra72x.dtsi and dra74x.dtsi */
+ status = disabled;
+ ti,hwmods = dss_core;
+ /* CTRL_CORE_DSS_PLL_CONTROL */
+ syscon-pll-ctrl = scm_conf 0x538;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,dra7-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ clocks = dss_dss_clk;
+ clock-names = fck;
+ /* CTRL_CORE_SMA_SW_1 */
+ syscon-pol = scm_conf 0x534;
+ };
+
+ hdmi: encoder@5806 {
+ compatible = ti,dra7-hdmi;
+ reg = 0x5804 0x200,
+ 0x58040200 0x80,
+ 0x58040300 0x80,
+ 0x5806 0x19000;
+ reg-names = wp, pll, phy, core;
+ interrupts = GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ ti,hwmods = dss_hdmi;
+ clocks = dss_48mhz_clk, dss_hdmi_clk;
+ clock-names = fck, sys_clk;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi
index e5a3d23a3df1..0866866c8e94 100644
--- a/arch/arm/boot/dts/dra72x.dtsi
+++ b/arch/arm/boot/dts/dra72x.dtsi
@@ -28,3 +28,14 @@
interrupts = GIC_SPI DIRECT_IRQ(131) IRQ_TYPE_LEVEL_HIGH;
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1;
+
+ clocks = dss_dss_clk,
+dss_video1_clk;
+ clock-names = fck, video1_clk;
+};
diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi
index 10173fab1a15..1a4f4970aaad 100644
--- a/arch/arm/boot/dts/dra74x.dtsi
+++ b/arch/arm/boot/dts/dra74x.dtsi
@@ -67,3 +67,18 @@
};
};
};
+
+dss {
+ reg = 0x5800 0x80,
+ 0x58004054 0x4,
+ 0x58004300 0x20,
+ 0x58005054 0x4,
+ 0x58005300 0x20;
+ reg-names = dss, pll1_clkctrl, pll1,
+ pll2_clkctrl, pll2;
+
+ clocks = dss_dss_clk,
+dss_video1_clk,
+dss_video2_clk;
+ clock-names = fck, video1_clk, video2_clk;
+};
--
2.3.3
--
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
[PATCHv2 00/10] ARM: DRA7: add display support
Hi, This series adds the arch/arm/ side of the display support for DRA7 (DRA72x, DRA74x, AM54xx) SoCs. Also support for HDMI output on x15 and DRA72 EVM boards is added. This series is v2, and is based on Tero's [PATCHv5 00/35] ARM: OMAP2+: PRCM/SCM cleanups against 4.0-rc series. The difference to v1 is that the DESHDCP clock is a real clock, even if we still always enable it at boot time. Tomi Tomi Valkeinen (10): arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk ARM: DRA7: hwmod: add DMM hwmod description ARM: DRA7: hwmod: set DSS submodule parent hwmods ARM: OMAP: display: change compat names to array ARM: OMAP2+: display: detect DRA7 DSS arm/dts: dra7.dtsi: add DSS support arm/dts: dra72-evm.dts: add HDMI arm/dts: am57xx-beagle-x15.dts: add HDMI arm: dra7: add DESHDCP clock CLK: TI: always enable DESHDCP clock arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 ++ arch/arm/boot/dts/dra7.dtsi | 43 arch/arm/boot/dts/dra72-evm.dts | 110 ++ arch/arm/boot/dts/dra72x.dtsi | 11 +++ arch/arm/boot/dts/dra74x.dtsi | 15 arch/arm/boot/dts/dra7xx-clocks.dtsi | 11 +++ arch/arm/mach-omap2/display.c | 32 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 33 + drivers/clk/ti/clk-7xx.c | 8 ++- 9 files changed, 328 insertions(+), 16 deletions(-) -- 2.3.3 -- 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
[PATCHv2 07/10] arm/dts: dra72-evm.dts: add HDMI
DRA72 EVM has a HDMI output. This patch adds the device tree nodes
required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra72-evm.dts | 110
1 file changed, 110 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 4d8711713610..c752d7aa302d 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -19,6 +19,10 @@
reg = 0x8000 0x4000; /* 1024 MB */
};
+ aliases {
+ display0 = hdmi0;
+ };
+
evm_3v3: fixedregulator-evm_3v3 {
compatible = regulator-fixed;
regulator-name = evm_3v3;
@@ -35,6 +39,51 @@
compatible = linux,extcon-usb-gpio;
id-gpio = pcf_gpio_21 2 GPIO_ACTIVE_HIGH;
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = pcf_hdmi 4 GPIO_ACTIVE_HIGH, /* P4, CT CP HPD */
+ pcf_hdmi 5 GPIO_ACTIVE_HIGH, /* P5, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -45,6 +94,13 @@
;
};
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins =
+ 0x2b4 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda
*/
+ 0x2b8 (PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl
*/
+ ;
+ };
+
nand_default: nand_default {
pinctrl-single,pins =
0x0 (PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
@@ -144,6 +200,19 @@
0xb8 (PIN_OUTPUT | MUX_MODE1) /* gpmc_cs2.qspi1_cs0 */
;
};
+
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl
*/
+ 0x40c (PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda
*/
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ ;
+ };
};
i2c1 {
@@ -280,6 +349,27 @@
};
};
+i2c5 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = i2c5_pins;
+ clock-frequency = 40;
+
+ pcf_hdmi: pcf8575@26 {
+ compatible = nxp,pcf8575;
+ reg = 0x26;
+ gpio-controller;
+ #gpio-cells = 2;
+ /*
+* initial state is used here to keep the mdio interface
+* selected on RU89 through SEL_VIN4_MUX_S0, VIN2_S1 and
+* VIN2_S0 driven high otherwise Ethernet stops working
+* VIN6_SEL_S0 is low, thus selecting McASP3 over VIN6
+*/
+ lines-initial-states = 0x0f2b;
+ };
+};
+
uart1 {
status = okay;
};
@@ -569,3 +659,23 @@
};
};
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldo5_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.3.3
--
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
[PATCHv2 10/10] CLK: TI: always enable DESHDCP clock
DESHDCP clock is needed on DRA7 based SoCs to enable the DSS IP. That
clock is an odd one, as it is not supposed to be any kind of core clock
for DSS, and we don't even support HDCP, but the clock is still needed
even for the HWMOD framework to be able to reset the DSS IP.
As there's no support for multiple core clocks in the HWMOD framework,
we don't have any obvious place to enable this clock when DSS IP is
being enabled.
Furthermore, the HDMI on OMAP5 DSS is the same as on DRA7, and OMAP5
does not have any such clock configuration bit. This suggests that on
OMAP5 the DESHDCP clock is always enabled, and for DRA7 we have the
possibility to gate it.
So, as we don't have any clean way to enable and disable the clock
based on the need, this patch enables the clock at boot time, making it
work similarly to OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/clk-7xx.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 7b859ec31a14..e132d0677c03 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -308,7 +308,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
int __init dra7xx_dt_clk_init(void)
{
int rc;
- struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+ struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck, *hdcp_ck;
ti_dt_clocks_register(dra7xx_clks);
@@ -344,5 +344,10 @@ int __init dra7xx_dt_clk_init(void)
if (rc)
pr_err(%s: failed to set USB_DPLL M2 OUT\n, __func__);
+ hdcp_ck = clk_get_sys(NULL, dss_deshdcp_clk);
+ rc = clk_prepare_enable(hdcp_ck);
+ if (rc)
+ pr_err(%s: failed to set dss_deshdcp_clk\n, __func__);
+
return rc;
}
--
2.3.3
--
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
[PATCHv2 02/10] ARM: DRA7: hwmod: add DMM hwmod description
Add DMM hwmod entries for DRA7. This is identical to DMM on OMAP5.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e8692e7675b8..c236ea9bb940 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -49,6 +49,27 @@
*/
/*
+ * 'dmm' class
+ * instance(s): dmm
+ */
+static struct omap_hwmod_class dra7xx_dmm_hwmod_class = {
+ .name = dmm,
+};
+
+/* dmm */
+static struct omap_hwmod dra7xx_dmm_hwmod = {
+ .name = dmm,
+ .class = dra7xx_dmm_hwmod_class,
+ .clkdm_name = emif_clkdm,
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = DRA7XX_CM_EMIF_DMM_CLKCTRL_OFFSET,
+ .context_offs = DRA7XX_RM_EMIF_DMM_CONTEXT_OFFSET,
+ },
+ },
+};
+
+/*
* 'l3' class
* instance(s): l3_instr, l3_main_1, l3_main_2
*/
@@ -2313,6 +2334,14 @@ static struct omap_hwmod dra7xx_wd_timer2_hwmod = {
* Interfaces
*/
+/* l3_main_1 - dmm */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__dmm = {
+ .master = dra7xx_l3_main_1_hwmod,
+ .slave = dra7xx_dmm_hwmod,
+ .clk= l3_iclk_div,
+ .user = OCP_USER_SDMA,
+};
+
/* l3_main_2 - l3_instr */
static struct omap_hwmod_ocp_if dra7xx_l3_main_2__l3_instr = {
.master = dra7xx_l3_main_2_hwmod,
@@ -3265,6 +3294,7 @@ static struct omap_hwmod_ocp_if dra7xx_l4_wkup__wd_timer2
= {
};
static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
+ dra7xx_l3_main_1__dmm,
dra7xx_l3_main_2__l3_instr,
dra7xx_l4_cfg__l3_main_1,
dra7xx_mpu__l3_main_1,
--
2.3.3
--
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
[PATCHv2 08/10] arm/dts: am57xx-beagle-x15.dts: add HDMI
AM57xx Beagle X15 has a HDMI output. This patch adds the device tree
nodes required for HDMI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/am57xx-beagle-x15.dts | 81 +
1 file changed, 81 insertions(+)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 03750af3b49a..7184fc16d31e 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -19,6 +19,7 @@
aliases {
rtc0 = mcp_rtc;
rtc1 = tps659038_rtc;
+ display0 = hdmi0;
};
memory {
@@ -102,6 +103,51 @@
pinctrl-names = default;
pinctrl-0 = extcon_usb2_pins;
};
+
+ hdmi0: connector {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ type = a;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+ };
+
+ tpd12s015: encoder {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = gpio7 10 GPIO_ACTIVE_HIGH, /* gpio7_10, CT CP HPD
*/
+ gpio6 28 GPIO_ACTIVE_HIGH, /* gpio6_28, LS OE */
+ gpio7 12 GPIO_ACTIVE_HIGH; /* gpio7_12/sp1_cs2,
HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
};
dra7_pmx_core {
@@ -121,6 +167,13 @@
;
};
+ hdmi_pins: pinmux_hdmi_pins {
+ pinctrl-single,pins =
+ 0x408 (PIN_INPUT | MUX_MODE1) /*
i2c2_sda.hdmi1_ddc_scl */
+ 0x40c (PIN_INPUT | MUX_MODE1) /*
i2c2_scl.hdmi1_ddc_sda */
+ ;
+ };
+
i2c3_pins_default: i2c3_pins_default {
pinctrl-single,pins =
0x2a4 (PIN_INPUT| MUX_MODE10) /*
mcasp1_aclkx.i2c3_sda */
@@ -277,6 +330,14 @@
0x3e8 (PIN_INPUT_PULLUP | MUX_MODE14) /*
uart1_ctsn.gpio7_24 */
;
};
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x3b0 (PIN_OUTPUT | MUX_MODE14) /* gpio7_10
CT_CP_HPD */
+ 0x3b8 (PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD
*/
+ 0x370 (PIN_OUTPUT | MUX_MODE14) /* gpio6_28
LS_OE */
+ ;
+ };
};
i2c1 {
@@ -560,3 +621,23 @@
usb2 {
dr_mode = peripheral;
};
+
+dss {
+ status = ok;
+
+ vdda_video-supply = ldoln_reg;
+};
+
+hdmi {
+ status = ok;
+ vdda-supply = ldo3_reg;
+
+ pinctrl-names = default;
+ pinctrl-0 = hdmi_pins;
+
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+ };
+};
--
2.3.3
--
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
[PATCHv2 01/10] arm/dts: dra7xx: add 'ti,set-rate-parent' for dss_dss_clk
We need set-rate-parent flags for the display's clock path so that the
DSS driver can change the clock rate of the PLL.
This patchs adds the ti,set-rate-parent flag to 'dss_dss_clk' clock
node, which is only a gate clock, allowing the setting of the clock rate
to propagate to the PLL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: devicet...@vger.kernel.org
---
arch/arm/boot/dts/dra7xx-clocks.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 4bdcbd61ce47..0d76233840e6 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -1451,6 +1451,7 @@
clocks = dpll_per_h12x2_ck;
ti,bit-shift = 8;
reg = 0x1120;
+ ti,set-rate-parent;
};
dss_hdmi_clk: dss_hdmi_clk {
--
2.3.3
--
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
[PATCHv2 05/10] ARM: OMAP2+: display: detect DRA7 DSS
Add platform code to detect DRA7 DSS.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 9868d0bc7805..6ab13d18c636 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -287,6 +287,8 @@ static enum omapdss_version __init
omap_display_get_version(void)
return OMAPDSS_VER_OMAP5;
else if (soc_is_am43xx())
return OMAPDSS_VER_AM43xx;
+ else if (soc_is_dra7xx())
+ return OMAPDSS_VER_DRA7xx;
else
return OMAPDSS_VER_UNKNOWN;
}
@@ -573,6 +575,7 @@ static const char * const omapdss_compat_names[]
__initconst = {
ti,omap3-dss,
ti,omap4-dss,
ti,omap5-dss,
+ ti,dra7-dss,
};
struct device_node * __init omapdss_find_dss_of_node(void)
--
2.3.3
--
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
[PATCHv2 04/10] ARM: OMAP: display: change compat names to array
Simplify the DSS detection logic by creating a list of the omapdss
compat strings, instead of checking each separately with an 'if'.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/display.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index f492ae147c6a..9868d0bc7805 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -568,25 +568,24 @@ void __init omapdss_early_init_of(void)
}
+static const char * const omapdss_compat_names[] __initconst = {
+ ti,omap2-dss,
+ ti,omap3-dss,
+ ti,omap4-dss,
+ ti,omap5-dss,
+};
+
struct device_node * __init omapdss_find_dss_of_node(void)
{
struct device_node *node;
+ int i;
- node = of_find_compatible_node(NULL, NULL, ti,omap2-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap3-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap4-dss);
- if (node)
- return node;
-
- node = of_find_compatible_node(NULL, NULL, ti,omap5-dss);
- if (node)
- return node;
+ for (i = 0; i ARRAY_SIZE(omapdss_compat_names); ++i) {
+ node = of_find_compatible_node(NULL, NULL,
+ omapdss_compat_names[i]);
+ if (node)
+ return node;
+ }
return NULL;
}
--
2.3.3
--
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
[PATCHv2 09/10] arm: dra7: add DESHDCP clock
Add a new Linux clock for DRA7 based SoCs to control DESHDCP clock.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 5 +
arch/arm/boot/dts/dra7xx-clocks.dtsi | 10 ++
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 1 +
drivers/clk/ti/clk-7xx.c | 1 +
4 files changed, 17 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 312ede660b23..c06f30a76f5c 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -123,6 +123,11 @@
regulator-max-microvolt
= 300;
};
};
+
+ scm_conf_clocks: clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
dra7_pmx_core: pinmux@1400 {
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 0d76233840e6..a93754cf5e2f 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -2057,3 +2057,13 @@
clocks = dpll_usb_ck;
};
};
+
+scm_conf_clocks {
+ dss_deshdcp_clk: dss_deshdcp_clk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = l3_iclk_div;
+ ti,bit-shift = 0;
+ reg = 0x558;
+ };
+};
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 0411b838b4fa..97e3d7a62729 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -459,6 +459,7 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
{ .role = video2_clk, .clk = dss_video2_clk },
{ .role = video1_clk, .clk = dss_video1_clk },
{ .role = hdmi_clk, .clk = dss_hdmi_clk },
+ { .role = hdcp_clk, .clk = dss_deshdcp_clk },
};
static struct omap_hwmod dra7xx_dss_hwmod = {
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index ee32f4deebf4..7b859ec31a14 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -301,6 +301,7 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(48824000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(48826000.timer, timer_sys_ck, timer_sys_clk_div),
DT_CLK(NULL, sys_clkin, sys_clkin1),
+ DT_CLK(NULL, dss_deshdcp_clk, dss_deshdcp_clk),
{ .node_name = NULL },
};
--
2.3.3
--
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
[PATCHv2 03/10] ARM: DRA7: hwmod: set DSS submodule parent hwmods
Set DSS core hwmod as the parent for all the DSS submodules.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index c236ea9bb940..0411b838b4fa 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -521,6 +521,7 @@ static struct omap_hwmod dra7xx_dss_dispc_hwmod = {
},
},
.dev_attr = dss_dispc_dev_attr,
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
@@ -562,6 +563,7 @@ static struct omap_hwmod dra7xx_dss_hdmi_hwmod = {
},
.opt_clks = dss_hdmi_opt_clks,
.opt_clks_cnt = ARRAY_SIZE(dss_hdmi_opt_clks),
+ .parent_hwmod = dra7xx_dss_hwmod,
};
/*
--
2.3.3
--
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/7] Use DRM component API in tilcdc to connect to tda998x
On 03/24/15 14:50, Tomi Valkeinen wrote: Hi, On 18/03/15 11:06, Jyri Sarha wrote: I think the patches 1-5 are ready for merging. See the details below. I applied these on top of v4.0-rc3, booted up BBB, and loaded the modules. After doing that and waiting a few secs: # ./s-bbb.sh [ 15.237139] sysrq: SysRq : Changing Loglevel [ 15.241646] sysrq: Loglevel set to 9 [ 15.319762] [drm] Initialized drm 1.1.0 20060810 [ 15.588122] tda998x 0-0070: found TDA19988 [ 15.594824] tilcdc 4830e000.lcdc: bound 0-0070 (ops tda998x_ops [tda998x]) [ 15.602034] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 15.609011] [drm] No driver support for vblank timestamp query. [ 15.700798] tilcdc 4830e000.lcdc: fb0: frame buffer device [ 15.706757] tilcdc 4830e000.lcdc: registered panic notifier [ 15.712659] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0 # # [ 25.789364] [ cut here ] [ 25.794315] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 25.805999] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 25.812325] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g5fbf26ebaf12 #7 [ 25.820893] Hardware name: Generic AM33XX (Flattened Device Tree) [ 25.827359] Workqueue: events output_poll_execute [drm_kms_helper] [ 25.833819] Backtrace: [ 25.836439] [c0013550] (dump_backtrace) from [c0013764] (show_stack+0x18/0x1c) [ 25.844380] r6:c09d4228 r5:c09d4228 r4: r3:dd3604c0 [ 25.850338] [c001374c] (show_stack) from [c066bbc0] (dump_stack+0xa4/0xd4) [ 25.857927] [c066bb1c] (dump_stack) from [c0044d28] (warn_slowpath_common+0x84/0xc0) [ 25.866401] r6:010d r5:bf0a010c r4: r3:dd3604c0 [ 25.872348] [c0044ca4] (warn_slowpath_common) from [c0044e08] (warn_slowpath_null+0x24/0x2c) [ 25.881543] r8:dd50 r7:000f r6:bf0a25f0 r5:dd6b1400 r4:dd4e6800 [ 25.888617] [c0044de4] (warn_slowpath_null) from [bf0a010c] (tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]) [ 25.898849] [bf09fb20] (tilcdc_crtc_mode_set [tilcdc]) from [bf06d874] (drm_crtc_helper_set_mode+0x2b0/0x4f0 [drm_kms_helper]) [ 25.911132] r10:dd4e6bf0 r9:dd4e6800 r8:dd4e2e80 r7:dd6b1400 r6:0001 r5:dd50 [ 25.919372] r4:bf09fb20 [ 25.922061] [bf06d5c4] (drm_crtc_helper_set_mode [drm_kms_helper]) from [bf06e450] (drm_crtc_helper_set_config+0x768/0x9c8 [drm_kms_helper]) [ 25.935612] r10: r9:dd73d980 r8:dd4e6bf0 r7:bf031808 r6:dd4e6be4 r5:dd4e6bd8 [ 25.943827] r4:dd50 [ 25.946758] [bf06dce8] (drm_crtc_helper_set_config [drm_kms_helper]) from [bf00dcfc] (drm_mode_set_config_internal+0x6c/0xf4 [drm]) [ 25.959518] r10:0001 r9: r8:dd4b4b40 r7:dd50 r6:0001 r5:0028 [ 25.967767] r4:dd4b46c0 [ 25.970558] [bf00dc90] (drm_mode_set_config_internal [drm]) from [bf077a88] (restore_fbdev_mode+0xe0/0x100 [drm_kms_helper]) [ 25.982672] r7:dd73d980 r6:0001 r5:0028 r4: [ 25.988698] [bf0779a8] (restore_fbdev_mode [drm_kms_helper]) from [bf0799cc] (drm_fb_helper_restore_fbdev_mode_unlocked+0x24/0x64 [drm_kms_helper]) [ 26.002884] r9:dd4e6be4 r8:bf031808 r7:dd4e6800 r6:dd4e6800 r5:dd4b46c0 r4:dd4b4b40 [ 26.011104] [bf0799a8] (drm_fb_helper_restore_fb Tomi dev_mode_unlocked [drm_kms_helper]) from [bf079a2c] (drm_fb_helper_set_par+0x20/0x3c [drm_kms_helper]) [ 26.025562] r6:dd4e6800 r5:dd4b46c0 r4: r3: [ 26.031556] [bf079a0c] (drm_fb_helper_set_par [drm_kms_helper]) from [bf079968] (drm_fb_helper_hotplug_event+0x90/0xd0 [drm_kms_helper]) [ 26.044753] r4:dd4b4b40 r3: [ 26.048557] [bf0798d8] (drm_fb_helper_hotplug_event [drm_kms_helper]) from [bf07a7c4] (drm_fbdev_cma_hotplug_event+0x18/0x1c [drm_kms_helper]) [ 26.062289] r7:dd4e6a40 r6:0001 r5:dd4e6c38 r4:dd4e6800 [ 26.068300] [bf07a7ac] (drm_fbdev_cma_hotplug_event [drm_kms_helper]) from [bf0a217c] (tilcdc_fb_output_poll_changed+0x18/0x1c [tilcdc]) [ 26.081521] [bf0a2164] (tilcdc_fb_output_poll_changed [tilcdc]) from [bf06f388] (drm_kms_helper_hotplug_event+0x2c/0x30 [drm_kms_helper]) [ 26.094840] [bf06f35c] (drm_kms_helper_hotplug_event [drm_kms_helper]) from [bf06f448] (output_poll_execute+0x6c/0x18c [drm_kms_helper]) [ 26.108027] r4:dd4e6bd8 r3: [ 26.111809] [bf06f3dc] (output_poll_execute [drm_kms_helper]) from [c005c704] (process_one_work+0x1e8/0x560) [ 26.122456] r10:dfa1b700 r9: r8:c0a0c0b8 r Tomi 7:dd51deb0 r6:dfa157c0 r5:dd4b4d40 [ 26.130696] r4:dd4e6c38 [ 26.133353] [c005c51c] (process_one_work) from [c005d42c] (worker_thread+0x160/0x4c4) [ 26.141914] r10:dfa157c0 r9:0008 r8:dd4b4d58 r7:dd4b4d40 r6:c005d304 r5:dfa157f0 [ 26.150153] r4:dfa157c0 [ 26.152812] [c005d2cc] (worker_thread) from [c0061e38] (kthread+0xf0/0x110) [ 26.160465] r10: r9: r8: r7:c005d2cc r6:dd4b4d40 r5:dd509cc0 [ 26.168704] r4: [
Re: [GIT PULL] OMAP2+: TI clock driver changes for 4.1 merge window
Quoting Tero Kristo (2015-03-24 12:06:41) Hi Mike, Here are the TI clock driver patches meant for 4.1 merge window. Some simple data fixes, dm81xx FAPLL changes, and a generic TI clock driver register access fix taken from the PRCM/SCM set I have posted to linux-omap list earlier. Pulled. Thanks, Mike -Tero The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-4.1-clk-ti for you to fetch changes up to 9089848d9afa34a796988b5b666c2c4e611ccb61: clk: ti: Implement FAPLL set_rate for the PLL (2015-03-24 20:26:14 +0200) Peter Ujfalusi (2): clk: ti: clk-3xxx: Correct McBSP related DT clock definitions clk: ti: clk-3xxx-legacy: Correct McBSP related clock aliases Suman Anna (4): clk: ti: OMAP4: Remove the legacy timer DT clock aliases clk: ti: OMAP5: Correct the DT clock aliases for timers clk: ti: DRA7: Correct timer_sys_ck clock aliases for Timers clk: ti: DRA7: Add timer_sys_ck aliases for Timers 13 through 16 Tero Kristo (1): clk: ti: fix ti_clk_get_reg_addr error handling Tony Lindgren (3): clk: ti: Fix FAPLL recalc_rate for rounding errors clk: ti: Implement FAPLL set_rate for the synthesizer clk: ti: Implement FAPLL set_rate for the PLL drivers/clk/ti/apll.c|5 +- drivers/clk/ti/autoidle.c|2 +- drivers/clk/ti/clk-3xxx-legacy.c | 16 ++- drivers/clk/ti/clk-3xxx.c| 19 +-- drivers/clk/ti/clk-44xx.c| 11 -- drivers/clk/ti/clk-54xx.c| 22 ++-- drivers/clk/ti/clk-7xx.c | 18 ++- drivers/clk/ti/clk.c |7 +- drivers/clk/ti/divider.c |4 +- drivers/clk/ti/dpll.c|6 +- drivers/clk/ti/fapll.c | 270 -- drivers/clk/ti/gate.c|4 +- drivers/clk/ti/interface.c |2 +- drivers/clk/ti/mux.c |4 +- 14 files changed, 318 insertions(+), 72 deletions(-) -- 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
OMAP baseline test results for v4.0-rc5
Here are some basic OMAP test results for Linux v4.0-rc5. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.0-rc5/20150324122259/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-som, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: FAIL ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (15/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_oldconfig, multi_v7_defconfig Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 2420n800 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 5430es2sbct54 Kernel warnings during boot to userspace: FAIL ( 3/17): 4430es2panda, 4460varsomom, cmt3517 PM: chip retention via suspend: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/12): am335xbonelt, 4430es2panda, 4460varsomom, 2430sdp, 5430es2uevm, 5430es2sbct54 Pass ( 6/12): 4460pandaes, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: Pass ( 4/ 4): 37xxevm, 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 2/17): 4430es2panda, 4460varsomom Obsolete Kconfig symbols: FAIL ( 2/20): omap1_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.0-rc4 (06e5801b8cb3fc057d88cb4dc03c0b64b2744cda)): text data bsstotal kernel -400 -4 omap1_defconfig -4 +320 +28 omap1_defconfig_1510innovator_only -4 +320 +28 omap1_defconfig_5912osk_only -576 -80 -584 multi_v7_defconfig -84 +640 -20 omap2plus_defconfig -12400 -124 omap2plus_defconfig_2430sdp_only -20 +640 +44 omap2plus_defconfig_am33xx_only -84 +640 -20 omap2plus_defconfig_am43xx_only -84 +640 -20
Re: [PATCH v3] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used
On 03/20/2015 01:31 PM, Jyri Sarha wrote:
Set rule constraints to allow only combinations of sample-rate,
sample-format, and channels counts that can be played/captured with
reasonable sample-rate accuracy.
The logic with tdm-slots and serializers (=i2s data wires) goes like
this: The first wire will take all channels up to number of tdm-slots,
before following wires (if any) are used. If the first wire is used
fully, the remaining wires share the same clocks and the divider can
be calculated for the first wire.
Also, takes the number of tdm-slots into account when implicitly
selecting the BLCK divider.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
Previous version of the patch:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-March/089319.html
Since v2 I changed the SNDRV_PCM_HW_PARAM_SAMPLE_BITS rule in the to
SNDRV_PCM_HW_PARAM_FORMAT rule.
Somehow the constraints with a SNDRV_PCM_HW_PARAM_SAMPLE_BITS rule
using snd_interval_list() converged to an empty set when ever I tried
to play a format that could not pass the rule with any channel count
or rate, resulting all too familiar assertion in alsa-lib. However,
the direct tampering with SNDRV_PCM_HW_PARAM_FORMAT mask appears to
work as it should.
In addition to SAMPLE_BITS- to FORMAT-rule change I optimized the rate
rule a bit so that it does not try the rates that are outside current
range. According to my tests this does not affect the behavior in any
other way but slightly speeds up the decision making.
sound/soc/davinci/davinci-mcasp.c | 207
--
1 file changed, 197 insertions(+), 10 deletions(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/davinci/davinci-mcasp.c
index d40b392..76156d18 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -27,6 +27,7 @@
#include linux/of_platform.h
#include linux/of_device.h
#include linux/platform_data/davinci_asp.h
+#include linux/math64.h
#include sound/asoundef.h
#include sound/core.h
@@ -65,6 +66,11 @@ struct davinci_mcasp_context {
boolpm_state;
};
+struct davinci_mcasp_ruledata {
+ struct davinci_mcasp *mcasp;
+ int serializers;
+};
+
struct davinci_mcasp {
struct snd_dmaengine_dai_dma_data dma_data[2];
void __iomem *base;
@@ -99,6 +105,8 @@ struct davinci_mcasp {
#ifdef CONFIG_PM_SLEEP
struct davinci_mcasp_context context;
#endif
+
+ struct davinci_mcasp_ruledata ruledata[2];
};
static inline void mcasp_set_bits(struct davinci_mcasp *mcasp, u32 offset,
@@ -868,6 +876,30 @@ static int mcasp_dit_hw_param(struct davinci_mcasp
*mcasp,
return 0;
}
+static int davinci_mcasp_calc_clk_div(struct davinci_mcasp *mcasp,
+ unsigned int bclk_freq,
+ int *error_ppm)
+{
+ int div = mcasp-sysclk_freq / bclk_freq;
+ int rem = mcasp-sysclk_freq % bclk_freq;
+
+ if (rem != 0) {
+ if (div == 0 ||
+ ((mcasp-sysclk_freq / div) - bclk_freq)
+ (bclk_freq - (mcasp-sysclk_freq / (div+1 {
+ div++;
+ rem = rem - bclk_freq;
+ }
+ }
+ if (error_ppm)
+ *error_ppm =
+ (div*100 + (int)div64_long(100LL*rem,
+(int)bclk_freq))
+ /div - 100;
+
+ return div;
+}
+
static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *cpu_dai)
@@ -883,16 +915,20 @@ static int davinci_mcasp_hw_params(struct
snd_pcm_substream *substream,
* the machine driver, we need to calculate the ratio.
*/
if (mcasp-bclk_master mcasp-bclk_div == 0 mcasp-sysclk_freq) {
- unsigned int bclk_freq = snd_soc_params_to_bclk(params);
- unsigned int div = mcasp-sysclk_freq / bclk_freq;
- if (mcasp-sysclk_freq % bclk_freq != 0) {
- if (((mcasp-sysclk_freq / div) - bclk_freq)
- (bclk_freq - (mcasp-sysclk_freq / (div+1
- div++;
- dev_warn(mcasp-dev,
- Inaccurate BCLK: %u Hz / %u != %u Hz\n,
- mcasp-sysclk_freq, div, bclk_freq);
- }
+ int channels = params_channels(params);
+ int rate = params_rate(params);
+ int sbits = params_width(params);
+ int ppm, div;
+
+ if (channels mcasp-tdm_slots)
+ channels = mcasp-tdm_slots;
+
+ div = davinci_mcasp_calc_clk_div(mcasp, rate*sbits*channels,
+
Re: [PATCH] ARM: omap2plus_defconfig: Enable EXTCON_USB_GPIO
On Tue, Mar 24, 2015 at 09:26:48AM -0500, Nishanth Menon wrote: On 12:19-20150324, Roger Quadros wrote: We need to enable EXTCON_USB_GPIO_USB and not EXTCON_GPIO_USB. Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB) Reported-by: Nishant Menon n...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/configs/omap2plus_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 04b4c8e..daf9412 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -391,7 +391,7 @@ CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXTCON=m -CONFIG_EXTCON_GPIO=m +CONFIG_EXTCON_USB_GPIO=m CONFIG_EXTCON_PALMAS=m CONFIG_TI_EMIF=m CONFIG_PWM=y -- 2.1.0 Yep and it finally works! Yipiee!! http://pastebin.ubuntu.com/10669565/ I don't see the peripheral side IRQ in /proc/interrupts. What's going on? Can you load g_zero or g_mass_storage and verify peripheral side also works ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] clk: ti: Implement FAPLL set_rate for the synthesizer
* Tony Lindgren t...@atomide.com [150323 08:58]:
* Tero Kristo t-kri...@ti.com [150323 06:25]:
This code is generating these compile time warnings for me:
CC drivers/clk/ti/fapll.o
drivers/clk/ti/fapll.c: In function ‘ti_fapll_synth_set_rate’:
drivers/clk/ti/fapll.c:394:5: warning: ‘synth_int_div’ may be used
uninitialized in this function [-Wuninitialized]
drivers/clk/ti/fapll.c:373:18: note: ‘synth_int_div’ was declared here
drivers/clk/ti/fapll.c:400:23: warning: ‘synth_frac_div’ may be used
uninitialized in this function [-Wuninitialized]
drivers/clk/ti/fapll.c:373:33: note: ‘synth_frac_div’ was declared here
Oops thanks will check. I did move this into a separate function
to make it more readable, probably happened at that point.
Updated version of this patch below, let me know if you want the
whole set reposted.
Regards,
Tony
8 ---
From: Tony Lindgren t...@atomide.com
Date: Mon, 16 Mar 2015 18:04:20 -0700
Subject: [PATCH] clk: ti: Implement FAPLL set_rate for the synthesizer
We can pretty much get any rate out of the FAPLL because of the fractional
divider. Let's first try just adjusting the post divider, and if that is
not enough, then reprogram both the fractional divider and the post divider.
Let's also add a define for the fixed SYNTH_PHASE_K instead of using 8.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Matthijs van Duin matthijsvand...@gmail.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/clk/ti/fapll.c
+++ b/drivers/clk/ti/fapll.c
@@ -12,6 +12,7 @@
#include linux/clk-provider.h
#include linux/delay.h
#include linux/err.h
+#include linux/math64.h
#include linux/of.h
#include linux/of_address.h
#include linux/clk/ti.h
@@ -47,6 +48,8 @@
/* Synthesizer frequency register */
#define SYNTH_LDFREQ BIT(31)
+#define SYNTH_PHASE_K 8
+#define SYNTH_MAX_INT_DIV 0xf
#define SYNTH_MAX_DIV_M0xff
struct fapll_data {
@@ -204,7 +207,7 @@ static unsigned long ti_fapll_synth_recalc_rate(struct
clk_hw *hw,
/*
* Synth frequency integer and fractional divider.
* Note that the phase output K is 8, so the result needs
-* to be multiplied by 8.
+* to be multiplied by SYNTH_PHASE_K.
*/
if (synth-freq) {
u32 v, synth_int_div, synth_frac_div, synth_div_freq;
@@ -215,7 +218,7 @@ static unsigned long ti_fapll_synth_recalc_rate(struct
clk_hw *hw,
synth_div_freq = (synth_int_div * 1000) + synth_frac_div;
rate *= 1000;
do_div(rate, synth_div_freq);
- rate *= 8;
+ rate *= SYNTH_PHASE_K;
}
/* Synth post-divider M */
@@ -224,11 +227,138 @@ static unsigned long ti_fapll_synth_recalc_rate(struct
clk_hw *hw,
return DIV_ROUND_UP_ULL(rate, synth_div_m);
}
+static unsigned long ti_fapll_synth_get_frac_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct fapll_synth *synth = to_synth(hw);
+ unsigned long current_rate, frac_rate;
+ u32 post_div_m;
+
+ current_rate = ti_fapll_synth_recalc_rate(hw, parent_rate);
+ post_div_m = readl_relaxed(synth-div) SYNTH_MAX_DIV_M;
+ frac_rate = current_rate * post_div_m;
+
+ return frac_rate;
+}
+
+static u32 ti_fapll_synth_set_frac_rate(struct fapll_synth *synth,
+ unsigned long rate,
+ unsigned long parent_rate)
+{
+ u32 post_div_m, synth_int_div = 0, synth_frac_div = 0, v;
+
+ post_div_m = DIV_ROUND_UP_ULL((u64)parent_rate * SYNTH_PHASE_K, rate);
+ post_div_m = post_div_m / SYNTH_MAX_INT_DIV;
+ if (post_div_m SYNTH_MAX_DIV_M)
+ return -EINVAL;
+ if (!post_div_m)
+ post_div_m = 1;
+
+ for (; post_div_m SYNTH_MAX_DIV_M; post_div_m++) {
+ synth_int_div = DIV_ROUND_UP_ULL((u64)parent_rate *
+SYNTH_PHASE_K *
+1000,
+rate * post_div_m);
+ synth_frac_div = synth_int_div % 1000;
+ synth_int_div /= 1000;
+
+ if (synth_int_div = SYNTH_MAX_INT_DIV)
+ break;
+ }
+
+ if (synth_int_div SYNTH_MAX_INT_DIV)
+ return -EINVAL;
+
+ v = readl_relaxed(synth-freq);
+ v = ~0x1fff;
+ v |= (synth_int_div SYNTH_MAX_INT_DIV) 24;
+ v |= (synth_frac_div 0xff);
+ v |= SYNTH_LDFREQ;
+ writel_relaxed(v, synth-freq);
+
+ return post_div_m;
+}
+
+static long ti_fapll_synth_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *parent_rate)
+{
+ struct fapll_synth *synth =
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
On 09:31-20150324, Ard Biesheuvel wrote: On 24 March 2015 at 01:45, Simon Horman ho...@verge.net.au wrote: Hi Ard, I have observe what appears to be a build regression in next-20150323 caused by 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page). # make ... arm-unknown-linux-gnueabi-ld:./arch/arm/kernel/vmlinux.lds:546: syntax error I have observed this using the cross-compiler that is available on kernel.org: https://www.kernel.org/pub/tools/crosstool/files/bin/x86_64/4.6.3/ # arm-unknown-linux-gnueabi-gcc --version arm-unknown-linux-gnueabi-gcc (GCC) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # arm-unknown-linux-gnueabi-ld --version GNU ld (GNU Binutils) 2.22 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Hi all, This is fixed now in next-20150324. Sorry for the trouble I think we now have a new error: (seen with omap2plus_defconfig) on next-20150324 : ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression make: *** [vmlinux] Error 1 cross compiler (from ubuntu 12.04): $ arm-linux-gnueabi-ld --version GNU ld (GNU Binutils for Ubuntu) 2.22 Copyright 2011 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. $ arm-linux-gnueabi-gcc --version arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. next-20150320 was the last kernel which was successfully built -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2plus_defconfig: Enable EXTCON_USB_GPIO
On 11:44-20150324, Felipe Balbi wrote:
On Tue, Mar 24, 2015 at 09:26:48AM -0500, Nishanth Menon wrote:
On 12:19-20150324, Roger Quadros wrote:
We need to enable EXTCON_USB_GPIO_USB and not
EXTCON_GPIO_USB.
Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB)
Reported-by: Nishant Menon n...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/configs/omap2plus_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 04b4c8e..daf9412 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -391,7 +391,7 @@ CONFIG_TI_EDMA=y
CONFIG_DMA_OMAP=y
# CONFIG_IOMMU_SUPPORT is not set
CONFIG_EXTCON=m
-CONFIG_EXTCON_GPIO=m
+CONFIG_EXTCON_USB_GPIO=m
CONFIG_EXTCON_PALMAS=m
CONFIG_TI_EMIF=m
CONFIG_PWM=y
--
2.1.0
Yep and it finally works! Yipiee!!
http://pastebin.ubuntu.com/10669565/
I don't see the peripheral side IRQ in /proc/interrupts. What's going
on? Can you load g_zero or g_mass_storage and verify peripheral side
also works ?
my board is remote atm and does not have the usb peripheral cable hooked in.
However, I did load g_zero and looks like 73 is registered.
root@am57xx-evm:~# cat /proc/interrupts
CPU0 CPU1
16: 0 0 CBAR 32 gp_timer
19: 2296 2083 GIC 27 arch_timer
22: 1 0 CBAR 4 l3-dbg-irq
23: 1 0 WUGEN 10 l3-app-irq
28: 6002 0 CBAR 8 omap-dma-engine
32: 2 0 4ae1.gpio 0 palmas
224: 0 0 4805d000.gpio 27 4809c000.mmc cd
254: 0 0 48051000.gpio 24 extcon_usb2
255: 0 0 48051000.gpio 25 extcon_usb1
295:507 0 CBAR 69 OMAP UART2
308:524 0 CBAR 51 4807.i2c
309: 6 0 CBAR 56 4806.i2c
310: 8334 0 CBAR 78 mmc0
311: 1451 0 CBAR 81 mmc1
312:233 0 CBAR 49 4a14.sata
313: 0 0 CBAR 217 rtc0
314: 5 0 CBAR 72 dwc3-omap
315: 2 0 CBAR 87 dwc3-omap
317:727 0 CBAR 335 48484000.ethernet
318: 22 0 CBAR 336 48484000.ethernet
331: 1 0 PRCM pinctrl
386: 1 0 pinctrl 584 OMAP UART2
387: 0 0palmas 8
4807.i2c:tps659038@58:tps659038_rtc
388: 0 0palmas 1
4807.i2c:tps659038@58:tps659038_pwr_button
389: 0 0 CBAR 2 mcp7941x
390:460 0 CBAR 71 xhci-hcd:usb1
391: 11 0 CBAR 73 dwc3
IPI0: 0 1 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 2723 3962 Rescheduling interrupts
IPI3: 0 0 Function call interrupts
IPI4:279214 Single function call interrupts
IPI5: 0 0 CPU stop interrupts
IPI6: 0 0 IRQ work interrupts
IPI7: 0 0 completion interrupts
Err: 0
Looking at arch/arm/boot/dts/am57xx-beagle-x15.dts
looks like extcon is used for both host and peripheral - am I mistaken - if I
am right,
then at least the host devices seem to work (usb storage).
extcon_usb1: extcon_usb1 {
compatible = linux,extcon-usb-gpio;
id-gpio = gpio7 25 GPIO_ACTIVE_HIGH;
pinctrl-names = default;
pinctrl-0 = extcon_usb1_pins;
};
extcon_usb2: extcon_usb2 {
compatible = linux,extcon-usb-gpio;
id-gpio = gpio7 24 GPIO_ACTIVE_HIGH;
pinctrl-names = default;
pinctrl-0 = extcon_usb2_pins;
};
...
usb2_phy1 {
phy-supply = ldousb_reg;
};
usb1 {
dr_mode = host;
pinctrl-names = default;
pinctrl-0 = usb1_pins;
};
omap_dwc3_1 {
extcon = extcon_usb1;
};
omap_dwc3_2 {
extcon = extcon_usb2;
};
usb2 {
dr_mode = peripheral;
};
Anything I am missing?
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap2plus_defconfig: Enable EXTCON_USB_GPIO
On Tue, Mar 24, 2015 at 11:57:54AM -0500, Nishanth Menon wrote: On 11:44-20150324, Felipe Balbi wrote: On Tue, Mar 24, 2015 at 09:26:48AM -0500, Nishanth Menon wrote: On 12:19-20150324, Roger Quadros wrote: We need to enable EXTCON_USB_GPIO_USB and not EXTCON_GPIO_USB. Fixes: c08a54c0ebeb (ARM: omap2plus_defconfig: Enable EXTCON_GPIO_USB) Reported-by: Nishant Menon n...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/configs/omap2plus_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 04b4c8e..daf9412 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -391,7 +391,7 @@ CONFIG_TI_EDMA=y CONFIG_DMA_OMAP=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXTCON=m -CONFIG_EXTCON_GPIO=m +CONFIG_EXTCON_USB_GPIO=m CONFIG_EXTCON_PALMAS=m CONFIG_TI_EMIF=m CONFIG_PWM=y -- 2.1.0 Yep and it finally works! Yipiee!! http://pastebin.ubuntu.com/10669565/ I don't see the peripheral side IRQ in /proc/interrupts. What's going on? Can you load g_zero or g_mass_storage and verify peripheral side also works ? my board is remote atm and does not have the usb peripheral cable hooked in. However, I did load g_zero and looks like 73 is registered. thanks, that should be enough :-) Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com -- balbi signature.asc Description: Digital signature
Re: [PATCHv2] ti-soc-thermal: request temperature periodically if hw can't do that itself
On Sun, Jan 18, 2015 at 09:24:47PM +0100, Pavel Machek wrote:
When periodic mode is not enabled, it is neccessary to force reads.
Signed-off-by: Pavel Machek pa...@ucw.cz
This is a malformed patch. here is patch output (or git am)
patching file drivers/thermal/ti-soc-thermal/ti-bandgap.c
patch: malformed patch at line 68: (english)
http://www.livejournal.com/~pavelmachek
I would really recommend you to use git to send your patches to avoid
such problems. Can you please resend this patch in its proper format?
diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
index 634b6ce..2fde78c 100644
--- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
+++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
@@ -43,6 +43,8 @@
#include ti-bandgap.h
+static int ti_bandgap_force_single_read(struct ti_bandgap *bgp, int id);
+
/*** Helper functions to access registers and their bitfields ***/
/**
@@ -852,14 +831,21 @@ int ti_bandgap_read_temperature(struct ti_bandgap *bgp,
int id,
if (ret)
return ret;
+ if (!TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
+ ret = ti_bandgap_force_single_read(bgp, id);
+ if (ret)
+ return ret;
+ }
+
spin_lock(bgp-lock);
temp = ti_bandgap_read_temp(bgp, id);
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Re: [PATCH v3] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used
On Fri, Mar 20, 2015 at 01:31:08PM +0200, Jyri Sarha wrote: Set rule constraints to allow only combinations of sample-rate, sample-format, and channels counts that can be played/captured with reasonable sample-rate accuracy. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 0/2] clk: ti: OMAP3: McBSP clock fixes
On 03/16/2015 12:40 PM, Peter Ujfalusi wrote: Hi, This series will fix the following error during boot (both DT and legacy boot): [0.307739] omap_hwmod: mcbsp2: _wait_target_ready failed: -16 [0.307769] omap_hwmod: mcbsp2: cannot be enabled for reset (3) The clock definitions/aliases for McBSP ports were not correct. In case of DT boot we still have the following warning printed from hwmod: [0.222900] omap_hwmod: mcbsp2_sidetone using broken dt data from mcbsp [0.225311] omap_hwmod: mcbsp3_sidetone using broken dt data from mcbsp These are there because mcbsp is using two hwmods in the DT and hwmod prints out a warning for these. In legacy mode we also have 2 hwmods for McBSP2/3. One for the McBSP itself and the other for the sidetone block attached to them. I'll try to look into this one next. Since this series fixes the _wait_target_ready issue, can this be sent for 4.0? I don't think this is a critical fix, the wait_target_ready issue has been around for ages. Queued for 4.1 though, thanks. -Tero Regards, Peter --- Peter Ujfalusi (2): clk: ti: clk-3xxx: Correct McBSP related DT clock definitions clk: ti: clk-3xxx-legacy: Correct McBSP related clock aliases drivers/clk/ti/clk-3xxx-legacy.c | 16 +--- drivers/clk/ti/clk-3xxx.c| 19 +++ 2 files changed, 16 insertions(+), 19 deletions(-) -- 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] OMAP2+: TI clock driver changes for 4.1 merge window
Hi Mike, Here are the TI clock driver patches meant for 4.1 merge window. Some simple data fixes, dm81xx FAPLL changes, and a generic TI clock driver register access fix taken from the PRCM/SCM set I have posted to linux-omap list earlier. -Tero The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-4.1-clk-ti for you to fetch changes up to 9089848d9afa34a796988b5b666c2c4e611ccb61: clk: ti: Implement FAPLL set_rate for the PLL (2015-03-24 20:26:14 +0200) Peter Ujfalusi (2): clk: ti: clk-3xxx: Correct McBSP related DT clock definitions clk: ti: clk-3xxx-legacy: Correct McBSP related clock aliases Suman Anna (4): clk: ti: OMAP4: Remove the legacy timer DT clock aliases clk: ti: OMAP5: Correct the DT clock aliases for timers clk: ti: DRA7: Correct timer_sys_ck clock aliases for Timers clk: ti: DRA7: Add timer_sys_ck aliases for Timers 13 through 16 Tero Kristo (1): clk: ti: fix ti_clk_get_reg_addr error handling Tony Lindgren (3): clk: ti: Fix FAPLL recalc_rate for rounding errors clk: ti: Implement FAPLL set_rate for the synthesizer clk: ti: Implement FAPLL set_rate for the PLL drivers/clk/ti/apll.c|5 +- drivers/clk/ti/autoidle.c|2 +- drivers/clk/ti/clk-3xxx-legacy.c | 16 ++- drivers/clk/ti/clk-3xxx.c| 19 +-- drivers/clk/ti/clk-44xx.c| 11 -- drivers/clk/ti/clk-54xx.c| 22 ++-- drivers/clk/ti/clk-7xx.c | 18 ++- drivers/clk/ti/clk.c |7 +- drivers/clk/ti/divider.c |4 +- drivers/clk/ti/dpll.c|6 +- drivers/clk/ti/fapll.c | 270 -- drivers/clk/ti/gate.c|4 +- drivers/clk/ti/interface.c |2 +- drivers/clk/ti/mux.c |4 +- 14 files changed, 318 insertions(+), 72 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] CLK: TI: Timer clock alias fixes
On 03/14/2015 12:58 AM, Suman Anna wrote: Hi Tero, Please find couple of cleanup/fixes on the DT clock aliases for the GPTimers. Patches are based on 4.0-rc1 and following is the summary of the changes, 1. Patch 1 is a cleanup for OMAP4 2. Patch 2 fixes the failures for OMAP5 if omap_dm_timer_set_source() API is called to set the parent of any timer using OMAP_TIMER_SRC_SYS_CLK. 3. Patch 3 is for DRA7 and fixes the parent to be set to timer_sys_clk_div and not sys_clkin2, which is an optional clock input. 4. Patch 4 adds the DT CLK aliases for GPTimers 13 through 16 on DRA7. These timer nodes are currently missing in DTS, and I will be sending the patches for them soon. Queued for 4.1, thanks! -Tero regards Suman Suman Anna (4): CLK: TI: OMAP4: Remove the legacy timer DT clock aliases CLK: TI: OMAP5: Correct the DT clock aliases for timers CLK: TI: DRA7: Correct timer_sys_ck clock aliases for Timers CLK: TI: DRA7: Add timer_sys_ck aliases for Timers 13 through 16 drivers/clk/ti/clk-44xx.c | 11 --- drivers/clk/ti/clk-54xx.c | 22 +++--- drivers/clk/ti/clk-7xx.c | 18 +++--- 3 files changed, 22 insertions(+), 29 deletions(-) -- 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: [PATCHv5 01/35] clk: ti: fix ti_clk_get_reg_addr error handling
On 03/20/2015 08:44 PM, Tero Kristo wrote:
There is a case where NULL can be a valid return value for
ti_clk_get_reg_addr, specifically the case where both the provider index
and register offsets are zero. In this case, the current error checking
against a NULL pointer will fail. Thus, change the API to return a
ERR_PTR value in an error case, and change all the users of this API to
check against IS_ERR instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
Acked-by: Michael Turquette mturque...@linaro.org
Queued this patch for 4.1 through ti clock driver.
-Tero
---
drivers/clk/ti/apll.c |5 +++--
drivers/clk/ti/autoidle.c |2 +-
drivers/clk/ti/clk.c |7 ---
drivers/clk/ti/divider.c |4 ++--
drivers/clk/ti/dpll.c |6 +++---
drivers/clk/ti/gate.c |4 ++--
drivers/clk/ti/interface.c |2 +-
drivers/clk/ti/mux.c |4 ++--
8 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index 72d9727..49baf38 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -203,7 +203,7 @@ static void __init of_dra7_apll_setup(struct device_node
*node)
ad-control_reg = ti_clk_get_reg_addr(node, 0);
ad-idlest_reg = ti_clk_get_reg_addr(node, 1);
- if (!ad-control_reg || !ad-idlest_reg)
+ if (IS_ERR(ad-control_reg) || IS_ERR(ad-idlest_reg))
goto cleanup;
ad-idlest_mask = 0x1;
@@ -384,7 +384,8 @@ static void __init of_omap2_apll_setup(struct device_node
*node)
ad-autoidle_reg = ti_clk_get_reg_addr(node, 1);
ad-idlest_reg = ti_clk_get_reg_addr(node, 2);
- if (!ad-control_reg || !ad-autoidle_reg || !ad-idlest_reg)
+ if (IS_ERR(ad-control_reg) || IS_ERR(ad-autoidle_reg) ||
+ IS_ERR(ad-idlest_reg))
goto cleanup;
clk = clk_register(NULL, clk_hw-hw);
diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c
index 8912ff8..e75c64c 100644
--- a/drivers/clk/ti/autoidle.c
+++ b/drivers/clk/ti/autoidle.c
@@ -119,7 +119,7 @@ int __init of_ti_clk_autoidle_setup(struct device_node
*node)
clk-name = node-name;
clk-reg = ti_clk_get_reg_addr(node, 0);
- if (!clk-reg) {
+ if (IS_ERR(clk-reg)) {
kfree(clk);
return -EINVAL;
}
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index e22b956..0ebe5c5 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -103,7 +103,8 @@ int __init ti_clk_retry_init(struct device_node *node,
struct clk_hw *hw,
* @index: register index from the clock node
*
* Builds clock register address from device tree information. This
- * is a struct of type clk_omap_reg.
+ * is a struct of type clk_omap_reg. Returns a pointer to the register
+ * address, or a pointer error value in failure.
*/
void __iomem *ti_clk_get_reg_addr(struct device_node *node, int index)
{
@@ -121,14 +122,14 @@ void __iomem *ti_clk_get_reg_addr(struct device_node
*node, int index)
if (i == CLK_MAX_MEMMAPS) {
pr_err(clk-provider not found for %s!\n, node-name);
- return NULL;
+ return ERR_PTR(-ENOENT);
}
reg-index = i;
if (of_property_read_u32_index(node, reg, index, val)) {
pr_err(%s must have reg[%d]!\n, node-name, index);
- return NULL;
+ return ERR_PTR(-EINVAL);
}
reg-offset = val;
diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index 6211893..ff5f117 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -530,8 +530,8 @@ static int __init ti_clk_divider_populate(struct
device_node *node,
u32 val;
*reg = ti_clk_get_reg_addr(node, 0);
- if (!*reg)
- return -EINVAL;
+ if (IS_ERR(*reg))
+ return PTR_ERR(*reg);
if (!of_property_read_u32(node, ti,bit-shift, val))
*shift = val;
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 81dc469..11478a5 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -390,18 +390,18 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
#endif
} else {
dd-idlest_reg = ti_clk_get_reg_addr(node, 1);
- if (!dd-idlest_reg)
+ if (IS_ERR(dd-idlest_reg))
goto cleanup;
dd-mult_div1_reg = ti_clk_get_reg_addr(node, 2);
}
- if (!dd-control_reg || !dd-mult_div1_reg)
+ if (IS_ERR(dd-control_reg) || IS_ERR(dd-mult_div1_reg))
goto cleanup;
if (dd-autoidle_mask) {
dd-autoidle_reg = ti_clk_get_reg_addr(node, 3);
- if (!dd-autoidle_reg)
+ if (IS_ERR(dd-autoidle_reg))
goto cleanup;
}
diff --git a/drivers/clk/ti/gate.c b/drivers/clk/ti/gate.c
index d493307..0c6fdfc 100644
---
Re: [PATCH 2/3] clk: ti: Implement FAPLL set_rate for the synthesizer
On 03/24/2015 06:37 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [150323 08:58]:
* Tero Kristo t-kri...@ti.com [150323 06:25]:
This code is generating these compile time warnings for me:
CC drivers/clk/ti/fapll.o
drivers/clk/ti/fapll.c: In function ‘ti_fapll_synth_set_rate’:
drivers/clk/ti/fapll.c:394:5: warning: ‘synth_int_div’ may be used
uninitialized in this function [-Wuninitialized]
drivers/clk/ti/fapll.c:373:18: note: ‘synth_int_div’ was declared here
drivers/clk/ti/fapll.c:400:23: warning: ‘synth_frac_div’ may be used
uninitialized in this function [-Wuninitialized]
drivers/clk/ti/fapll.c:373:33: note: ‘synth_frac_div’ was declared here
Oops thanks will check. I did move this into a separate function
to make it more readable, probably happened at that point.
Updated version of this patch below, let me know if you want the
whole set reposted.
Yes this is fine, all patches queued for 4.1, thanks!
-Tero
Regards,
Tony
8 ---
From: Tony Lindgren t...@atomide.com
Date: Mon, 16 Mar 2015 18:04:20 -0700
Subject: [PATCH] clk: ti: Implement FAPLL set_rate for the synthesizer
We can pretty much get any rate out of the FAPLL because of the fractional
divider. Let's first try just adjusting the post divider, and if that is
not enough, then reprogram both the fractional divider and the post divider.
Let's also add a define for the fixed SYNTH_PHASE_K instead of using 8.
Cc: Brian Hutchinson b.hutch...@gmail.com
Cc: Matthijs van Duin matthijsvand...@gmail.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/drivers/clk/ti/fapll.c
+++ b/drivers/clk/ti/fapll.c
@@ -12,6 +12,7 @@
#include linux/clk-provider.h
#include linux/delay.h
#include linux/err.h
+#include linux/math64.h
#include linux/of.h
#include linux/of_address.h
#include linux/clk/ti.h
@@ -47,6 +48,8 @@
/* Synthesizer frequency register */
#define SYNTH_LDFREQ BIT(31)
+#define SYNTH_PHASE_K 8
+#define SYNTH_MAX_INT_DIV 0xf
#define SYNTH_MAX_DIV_M 0xff
struct fapll_data {
@@ -204,7 +207,7 @@ static unsigned long ti_fapll_synth_recalc_rate(struct
clk_hw *hw,
/*
* Synth frequency integer and fractional divider.
* Note that the phase output K is 8, so the result needs
-* to be multiplied by 8.
+* to be multiplied by SYNTH_PHASE_K.
*/
if (synth-freq) {
u32 v, synth_int_div, synth_frac_div, synth_div_freq;
@@ -215,7 +218,7 @@ static unsigned long ti_fapll_synth_recalc_rate(struct
clk_hw *hw,
synth_div_freq = (synth_int_div * 1000) + synth_frac_div;
rate *= 1000;
do_div(rate, synth_div_freq);
- rate *= 8;
+ rate *= SYNTH_PHASE_K;
}
/* Synth post-divider M */
@@ -224,11 +227,138 @@ static unsigned long ti_fapll_synth_recalc_rate(struct
clk_hw *hw,
return DIV_ROUND_UP_ULL(rate, synth_div_m);
}
+static unsigned long ti_fapll_synth_get_frac_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct fapll_synth *synth = to_synth(hw);
+ unsigned long current_rate, frac_rate;
+ u32 post_div_m;
+
+ current_rate = ti_fapll_synth_recalc_rate(hw, parent_rate);
+ post_div_m = readl_relaxed(synth-div) SYNTH_MAX_DIV_M;
+ frac_rate = current_rate * post_div_m;
+
+ return frac_rate;
+}
+
+static u32 ti_fapll_synth_set_frac_rate(struct fapll_synth *synth,
+ unsigned long rate,
+ unsigned long parent_rate)
+{
+ u32 post_div_m, synth_int_div = 0, synth_frac_div = 0, v;
+
+ post_div_m = DIV_ROUND_UP_ULL((u64)parent_rate * SYNTH_PHASE_K, rate);
+ post_div_m = post_div_m / SYNTH_MAX_INT_DIV;
+ if (post_div_m SYNTH_MAX_DIV_M)
+ return -EINVAL;
+ if (!post_div_m)
+ post_div_m = 1;
+
+ for (; post_div_m SYNTH_MAX_DIV_M; post_div_m++) {
+ synth_int_div = DIV_ROUND_UP_ULL((u64)parent_rate *
+SYNTH_PHASE_K *
+1000,
+rate * post_div_m);
+ synth_frac_div = synth_int_div % 1000;
+ synth_int_div /= 1000;
+
+ if (synth_int_div = SYNTH_MAX_INT_DIV)
+ break;
+ }
+
+ if (synth_int_div SYNTH_MAX_INT_DIV)
+ return -EINVAL;
+
+ v = readl_relaxed(synth-freq);
+ v = ~0x1fff;
+ v |= (synth_int_div SYNTH_MAX_INT_DIV) 24;
+ v |= (synth_frac_div 0xff);
+ v |= SYNTH_LDFREQ;
+ writel_relaxed(v, synth-freq);
+
+ return post_div_m;
+}
+
+static long ti_fapll_synth_round_rate(struct clk_hw *hw, unsigned long rate,
+
Re: [PATCH 2/2] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
On 03/24/2015 01:06 PM, Paul Walmsley wrote:
On Mon, 16 Mar 2015, Suman Anna wrote:
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna s-a...@ti.com
This one results in compiler warnings:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c:1776:32: warning:
‘dra7xx_timer_secure_hwmod_class’ defined but not used [-Wunused-variable]
static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = {
Have queued the following for v4.1.
Thanks Paul. I will add it back when I post the hwmod for Timer 12, I
had the Timer12 locally in my tree, so missed the warning.
regards
Suman
- Paul
From: Suman Anna s-a...@ti.com
Date: Mon, 16 Mar 2015 15:54:54 -0500
Subject: [PATCH] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna s-a...@ti.com
[p...@pwsan.com: dropped dra7xx_timer_secure_hwmod_class and
dra7xx_timer_secure_sysc to avoid compiler warnings]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index d0f03e73add4..701234d8db1b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1763,21 +1763,6 @@ static struct omap_hwmod_class
dra7xx_timer_1ms_hwmod_class = {
.sysc = dra7xx_timer_1ms_sysc,
};
-static struct omap_hwmod_class_sysconfig dra7xx_timer_secure_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
-SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
-SIDLE_SMART_WKUP),
- .sysc_fields= omap_hwmod_sysc_type2,
-};
-
-static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = {
- .name = timer,
- .sysc = dra7xx_timer_secure_sysc,
-};
-
static struct omap_hwmod_class_sysconfig dra7xx_timer_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
@@ -1841,7 +1826,7 @@ static struct omap_hwmod dra7xx_timer3_hwmod = {
/* timer4 */
static struct omap_hwmod dra7xx_timer4_hwmod = {
.name = timer4,
- .class = dra7xx_timer_secure_hwmod_class,
+ .class = dra7xx_timer_hwmod_class,
.clkdm_name = l4per_clkdm,
.main_clk = timer4_gfclk_mux,
.prcm = {
--
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 v7 0/6] wlcore: add device-tree support
hi Nikita, On Tue, Mar 24, 2015 at 1:37 PM, Nikita Kiryanov nik...@compulab.co.il wrote: Hi Eliad, On 03/18/2015 06:38 PM, Eliad Peller wrote: Add device-tree support to the wlcore (wl12xx/wl18xx) driver. Update the current users to use the bindings instead of pdata-quirks. Finally, remove the deprecated wl12xx_platform_data struct (along with the da850 board file code that still uses it) Tested-by: Nikita Kiryanov nik...@compulab.co.il Tested on am437x-gp-evm with WL1835MODCOM8B thanks for testing it! Eliad. -- 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/7] Use DRM component API in tilcdc to connect to tda998x
On 24/03/15 16:28, Jyri Sarha wrote: I tried first with 3.19 and then with 4.0-rc5, checked the boot and then the modetest, but I could not reproduce the trace above. In my config I just have CONFIG_DRM=m and CONFIG_DRM_I2C_NXP_TDA998X=m on top of plain omap2plus_defconfig. Should I take something else? Anyway, I doubt this has anything to do with my patches. Could you give it one more try without my patches? 4.0-rc3 works ok for me without your patches. I can run modetest and I get a picture on the monitor. Well, not 100% ok. If I run my test app, I get BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:949. With your patches I get the warnings and I don't get anything on the screen. I've attached my kernel config. Hmm. The warning comes if tilcdc_crtc_mode_valid() fails (I think). My monitor is not a HDMI monitor. It has native mode 1920x1200@60, which cannot be produced by tilcdc, and on -rc3 the mode picked is 1280x960@60. Maybe this is somehow related? You're using a HDMI TV? What mode does it pick? Is it the native mode? Hmm, yes, I think it's related. Enabling debug prints shows: [ 32.361924] [drm:tilcdc_crtc_mode_valid] Processing mode 1920x1080@60 with pixel clock 148500 [ 32.370850] [drm:tilcdc_crtc_mode_valid] Pruning mode: pixel clock too high [ 32.378143] [ cut here ] [ 32.382993] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 32.394641] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 32.400964] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g944a1f8a79f1 #16 [ 32.409617] Hardware name: Generic AM33XX (Flattened Device Tree) So maybe your series removes some filtering somewhere, and illegal modes get passed forward? Tomi # # Automatically generated file; DO NOT EDIT. # Linux/arm 4.0.0-rc3 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y CONFIG_USELIB=y CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y # CONFIG_AUDITSYSCALL is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_ARCH_HAS_TICK_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y # CONFIG_NO_HZ_FULL is not set CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_RCU=y CONFIG_SRCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y # CONFIG_RCU_USER_QS is not set CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_RCU_FAST_NO_HZ is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_RCU_KTHREAD_PRIO=0 # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=16 CONFIG_LOG_CPU_MAX_BUF_SHIFT=12 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y CONFIG_CGROUP_CPUACCT=y CONFIG_PAGE_COUNTER=y CONFIG_MEMCG=y CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y CONFIG_MEMCG_KMEM=y CONFIG_CGROUP_PERF=y CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y CONFIG_RT_GROUP_SCHED=y CONFIG_BLK_CGROUP=y #
Re: [PATCH V2 2/2] ARM: dts: am57xx-beagle-x15: Add thermal map to include fan and tmp102
On Mon, Mar 23, 2015 at 02:39:39PM -0500, Nishanth Menon wrote:
BeagleBoard-X15 has capability for a fan and has an onboard TMP102
temperature sensor as well. This allows us to create a new thermal
zone (called, un-imaginatively board), and allows us to use some
active cooling as temperatures start edge upward in the system by
creating a new alert temperature (emperically 50C) for cpu.
NOTE: Fan is NOT mounted by default on the platform, in such a case,
all we end up doing is switch on a regulator and leak very minimal
current.
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Eduardo Valentin edubez...@gmail.com
---
Changes since V1:
- slight change in omap4-cpu-thermal for usage in am57xx-dtsi
- Not carrying forward ack due to change
V1: http://marc.info/?t=14268810274r=1w=2
arch/arm/boot/dts/am57xx-beagle-x15.dts | 49
++
arch/arm/boot/dts/omap4-cpu-thermal.dtsi |4 +--
2 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 41642fe770a1..6a3621c23017 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -86,6 +86,7 @@
gpios = tps659038_gpio 1 GPIO_ACTIVE_HIGH;
gpio-fan,speed-map = 0 0,
13000 1;
+ #cooling-cells = 2;
};
extcon_usb1: extcon_usb1 {
@@ -441,6 +442,7 @@
pinctrl-0 = tmp102_pins_default;
interrupt-parent = gpio7;
interrupts = 16 IRQ_TYPE_LEVEL_LOW;
+ #thermal-sensor-cells = 1;
};
};
@@ -559,3 +561,50 @@
usb2 {
dr_mode = peripheral;
};
+
+cpu_trips {
+ cpu_alert1: cpu_alert1 {
+ temperature = 5; /* millicelsius */
+ hysteresis = 2000; /* millicelsius */
+ type = active;
+ };
+};
+
+cpu_cooling_maps {
+ map1 {
+ trip = cpu_alert1;
+ cooling-device = gpio_fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT;
+ };
+};
+
+thermal_zones {
+ board_thermal: board_thermal {
+ polling-delay-passive = 1250; /* milliseconds */
+ polling-delay = 1500; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = tmp102 0;
+
+ board_trips: trips {
+ board_alert0: board_alert {
+ temperature = 4; /* millicelsius */
+ hysteresis = 2000; /* millicelsius */
+ type = active;
+ };
+
+ board_crit: board_crit {
+ temperature = 105000; /* millicelsius */
+ hysteresis = 0; /* millicelsius */
+ type = critical;
+ };
+ };
+
+ board_cooling_maps: cooling-maps {
+ map0 {
+ trip = board_alert0;
+ cooling-device =
+ gpio_fan THERMAL_NO_LIMIT THERMAL_NO_LIMIT;
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
index cb9458feb2e3..ab7f87ae96f0 100644
--- a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -18,7 +18,7 @@ cpu_thermal: cpu_thermal {
/* sensor ID */
thermal-sensors = bandgap 0;
-trips {
+ cpu_trips: trips {
cpu_alert0: cpu_alert {
temperature = 10; /* millicelsius */
hysteresis = 2000; /* millicelsius */
@@ -31,7 +31,7 @@ cpu_thermal: cpu_thermal {
};
};
- cooling-maps {
+ cpu_cooling_maps: cooling-maps {
map0 {
trip = cpu_alert0;
cooling-device =
--
1.7.9.5
signature.asc
Description: Digital signature
Re: [PATCH v3 0/7] Use DRM component API in tilcdc to connect to tda998x
On 03/24/15 17:16, Tomi Valkeinen wrote: On 24/03/15 16:28, Jyri Sarha wrote: I tried first with 3.19 and then with 4.0-rc5, checked the boot and then the modetest, but I could not reproduce the trace above. In my config I just have CONFIG_DRM=m and CONFIG_DRM_I2C_NXP_TDA998X=m on top of plain omap2plus_defconfig. Should I take something else? Anyway, I doubt this has anything to do with my patches. Could you give it one more try without my patches? 4.0-rc3 works ok for me without your patches. I can run modetest and I get a picture on the monitor. Well, not 100% ok. If I run my test app, I get BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:949. With your patches I get the warnings and I don't get anything on the screen. I've attached my kernel config. Hmm. The warning comes if tilcdc_crtc_mode_valid() fails (I think). My monitor is not a HDMI monitor. It has native mode 1920x1200@60, which cannot be produced by tilcdc, and on -rc3 the mode picked is 1280x960@60. Oh-o. That is the reason then. My HDMI TV also - wrongly - advertises having 1920x1200@60 mode. When that mode produced the error I did not think much of it and tested with other modes. Maybe this is somehow related? You're using a HDMI TV? What mode does it pick? Is it the native mode? Hmm, yes, I think it's related. Enabling debug prints shows: [ 32.361924] [drm:tilcdc_crtc_mode_valid] Processing mode 1920x1080@60 with pixel clock 148500 [ 32.370850] [drm:tilcdc_crtc_mode_valid] Pruning mode: pixel clock too high [ 32.378143] [ cut here ] [ 32.382993] WARNING: CPU: 0 PID: 50 at drivers/gpu/drm/tilcdc/tilcdc_crtc.c:269 tilcdc_crtc_mode_set+0x5ec/0x648 [tilcdc]() [ 32.394641] Modules linked in: tilcdc tda998x drm_kms_helper drm [ 32.400964] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 4.0.0-rc3-7-g944a1f8a79f1 #16 [ 32.409617] Hardware name: Generic AM33XX (Flattened Device Tree) So maybe your series removes some filtering somewhere, and illegal modes get passed forward? It indeed looks like that. The actual tilcdc_slave code does not have much much logic in it, but is sounds like the DRM slave encoder API and the DRM external encoder API are not entirely entirely compatible. I'll try to track this further. Thanks, Jyri -- 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 RFC] drm/tilcdc: Hijack external connectors helper funcs to filter modes
Hijack external connectors helper funcs to filter modes. TILCDC crtc
wants to have its say on which modes are valid. There appears to be no
trivial way to do that directly from crtc. This patch goes and hijacks
the external connectors helper functions and puts its own mode_valid()
function there. The original mode_valid() function is still called if
the mode is found suitable and the original helper funcs pointer is
restored when TILCDC is unloaded.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
This patch applies on top of my [PATCH v3 0/7] Use DRM component API
in tilcdc to connect to tda998x-patch set[1].
I am too new to DRM to know if what I am doing here is acceptable or
not. And I am too new to TILCDC to know if there is not someting
fundamentally wrong with it and that is why need to do this.
The code would certainly look nicer if there would be a mode_valid
func in crtc_helper_funcs too. Would such a patch be accepted?
Best regards,
Jyri
[1]http://www.spinics.net/lists/linux-omap/msg116923.html
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 9 +--
drivers/gpu/drm/tilcdc/tilcdc_drv.h | 1 +
drivers/gpu/drm/tilcdc/tilcdc_external.c | 43 +++-
drivers/gpu/drm/tilcdc/tilcdc_external.h | 1 +
4 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index eb7ed8f..1876945 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -110,6 +110,8 @@ static int tilcdc_unload(struct drm_device *dev)
{
struct tilcdc_drm_private *priv = dev-dev_private;
+ tilcdc_remove_external_encoders(dev);
+
drm_fbdev_cma_fini(priv-fbdev);
drm_kms_helper_poll_fini(dev);
drm_mode_config_cleanup(dev);
@@ -267,13 +269,13 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
if ((priv-num_encoders == 0) || (priv-num_connectors == 0)) {
dev_err(dev-dev, no encoders/connectors found\n);
ret = -ENXIO;
- goto fail_component_cleanup;
+ goto fail_external_cleanup;
}
ret = drm_vblank_init(dev, 1);
if (ret 0) {
dev_err(dev-dev, failed to initialize vblank\n);
- goto fail_component_cleanup;
+ goto fail_external_cleanup;
}
pm_runtime_get_sync(dev-dev);
@@ -318,6 +320,9 @@ fail_component_cleanup:
if (priv-is_componentized)
component_unbind_all(dev-dev, dev);
+fail_external_cleanup:
+ tilcdc_remove_external_encoders(dev);
+
fail_cpufreq_unregister:
pm_runtime_disable(dev-dev);
#ifdef CONFIG_CPU_FREQ
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 8ea3d11..ff1c3dd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -85,6 +85,7 @@ struct tilcdc_drm_private {
unsigned int num_connectors;
struct drm_connector *connectors[8];
+ struct drm_connector_helper_funcs *connector_funcs[8];
bool is_componentized;
};
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 1dd6c20..581b775 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -27,12 +27,34 @@ static const struct tilcdc_panel_info panel_info_tda998x = {
.raster_order = 0,
};
+static int tilcdc_external_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ struct tilcdc_drm_private *priv = connector-dev-dev_private;
+ int ret, i;
+
+ ret = tilcdc_crtc_mode_valid(priv-crtc, mode);
+ if (ret != MODE_OK)
+ return ret;
+
+ for (i = 0; i priv-num_connectors
+priv-connectors[i] != connector; i++);
+
+ BUG_ON(priv-connectors[i] != connector);
+
+ if (priv-connector_funcs[i]-mode_valid)
+ return priv-connector_funcs[i]-mode_valid(connector, mode);
+
+ return MODE_OK;
+}
+
static int tilcdc_add_external_encoder(struct drm_device *dev, int *bpp,
struct drm_connector *connector)
{
struct tilcdc_drm_private *priv = dev-dev_private;
+ struct drm_connector_helper_funcs *connector_funcs;
- priv-connectors[priv-num_connectors++] = connector;
+ priv-connectors[priv-num_connectors] = connector;
priv-encoders[priv-num_encoders++] = connector-encoder;
/* Only tda998x is supported at the moment. */
@@ -40,6 +62,14 @@ static int tilcdc_add_external_encoder(struct drm_device
*dev, int *bpp,
tilcdc_crtc_set_panel_info(priv-crtc, panel_info_tda998x);
*bpp = panel_info_tda998x.bpp;
+ priv-connector_funcs[priv-num_connectors] = connector-helper_private;
+ connector_funcs =
Re: [PATCHv5 29/35] ARM: dts: am4372: add minimal l4 bus layout with control module support
Hi Tero,
On 03/20/2015 01:44 PM, Kristo, Tero wrote:
This patch creates an l4_wkup interconnect for AM43xx, and moves some of
the generic peripherals under it. System control module nodes are moved
under this new interconnect also, and the SCM clock layout is changed
to use the renamed SCM nodea as the clock provider.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
Documentation/devicetree/bindings/arm/omap/l4.txt |1 +
.../devicetree/bindings/arm/omap/prcm.txt |2 +-
arch/arm/boot/dts/am4372.dtsi | 85
+++-
arch/arm/boot/dts/am43xx-clocks.dtsi |2 +-
arch/arm/mach-omap2/control.c |2 +-
5 files changed, 53 insertions(+), 39 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/l4.txt
b/Documentation/devicetree/bindings/arm/omap/l4.txt
index d333f0a..941b914 100644
--- a/Documentation/devicetree/bindings/arm/omap/l4.txt
+++ b/Documentation/devicetree/bindings/arm/omap/l4.txt
@@ -7,6 +7,7 @@ Required properties:
Should be ti,omap2-l4-wkup for OMAP2 family l4 wkup bus
Should be ti,omap3-l4-core for OMAP3 family l4 core bus
Should be ti,am3-l4-wkup for AM33xx family l4 wkup bus
+Should be ti,am4-l4-wkup for AM43xx family l4 wkup bus
- ranges : contains the IO map range for the bus
Examples:
diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt
b/Documentation/devicetree/bindings/arm/omap/prcm.txt
index c8e2027..8af4f32 100644
--- a/Documentation/devicetree/bindings/arm/omap/prcm.txt
+++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt
@@ -12,7 +12,7 @@ Required properties:
ti,am3-prcm
ti,am3-scm
ti,am4-prcm
- ti,am4-scrm
+ ti,am4-scm
ti,omap2-prcm
ti,omap2-scm
ti,omap3-prm
diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 1943fc3..9ed58115 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -57,22 +57,6 @@
cache-level = 2;
};
- am43xx_control_module: control_module@4a002000 {
- compatible = syscon;
- reg = 0x44e1 0x7f4;
- };
-
- am43xx_pinmux: pinmux@44e10800 {
- compatible = ti,am437-padconf, pinctrl-single;
- reg = 0x44e10800 0x31c;
- #address-cells = 1;
- #size-cells = 0;
- #interrupt-cells = 1;
- interrupt-controller;
- pinctrl-single,register-width = 32;
- pinctrl-single,function-mask = 0x;
- };
-
ocp {
compatible = ti,am4372-l3-noc, simple-bus;
#address-cells = 1;
@@ -84,29 +68,58 @@
interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
- prcm: prcm@44df {
- compatible = ti,am4-prcm;
- reg = 0x44df 0x11000;
-
- prcm_clocks: clocks {
- #address-cells = 1;
- #size-cells = 0;
- };
+ l4_wkup: l4_wkup@44c0 {
+ compatible = ti,am4-l4-wkup, simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges = 0 0x44c0 0x287000;
- prcm_clockdomains: clockdomains {
- };
- };
+ prcm: prcm@1f {
+ compatible = ti,am4-prcm;
+ reg = 0x1f 0x11000;
- scrm: scrm@44e1 {
- compatible = ti,am4-scrm;
- reg = 0x44e1 0x2000;
+ prcm_clocks: clocks {
+ #address-cells = 1;
+ #size-cells = 0;
+ };
- scrm_clocks: clocks {
- #address-cells = 1;
- #size-cells = 0;
+ prcm_clockdomains: clockdomains {
+ };
};
- scrm_clockdomains: clockdomains {
+ scm: scm@21 {
+ compatible = ti,am4-scm, simple-bus;
+ reg = 0x21 0x1000;
Any reason for choosing a different size here compared to AM335x. Also,
the scrm node above has 0x2000 as size. I found that I needed to
increase the size to 0x2000 here to accomodate the wkup_m3_ipc node on
top of your series. The node uses IPC registers which are part of the
Control module, so on AM335x, I added it as a child node of scm, but
here to do the same I
Re: [PATCH 2/2] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
On Mon, 16 Mar 2015, Suman Anna wrote:
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna s-a...@ti.com
This one results in compiler warnings:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c:1776:32: warning:
‘dra7xx_timer_secure_hwmod_class’ defined but not used [-Wunused-variable]
static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = {
Have queued the following for v4.1.
- Paul
From: Suman Anna s-a...@ti.com
Date: Mon, 16 Mar 2015 15:54:54 -0500
Subject: [PATCH] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
GPTimer 4 is a regular timer and not a secure timer, so fix
the hwmod to use the correct hwmod class (even though there
are no differences in the class definition itself).
Signed-off-by: Suman Anna s-a...@ti.com
[p...@pwsan.com: dropped dra7xx_timer_secure_hwmod_class and
dra7xx_timer_secure_sysc to avoid compiler warnings]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 17 +
1 file changed, 1 insertion(+), 16 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index d0f03e73add4..701234d8db1b 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1763,21 +1763,6 @@ static struct omap_hwmod_class
dra7xx_timer_1ms_hwmod_class = {
.sysc = dra7xx_timer_1ms_sysc,
};
-static struct omap_hwmod_class_sysconfig dra7xx_timer_secure_sysc = {
- .rev_offs = 0x,
- .sysc_offs = 0x0010,
- .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
- SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
- .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
- SIDLE_SMART_WKUP),
- .sysc_fields= omap_hwmod_sysc_type2,
-};
-
-static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = {
- .name = timer,
- .sysc = dra7xx_timer_secure_sysc,
-};
-
static struct omap_hwmod_class_sysconfig dra7xx_timer_sysc = {
.rev_offs = 0x,
.sysc_offs = 0x0010,
@@ -1841,7 +1826,7 @@ static struct omap_hwmod dra7xx_timer3_hwmod = {
/* timer4 */
static struct omap_hwmod dra7xx_timer4_hwmod = {
.name = timer4,
- .class = dra7xx_timer_secure_hwmod_class,
+ .class = dra7xx_timer_hwmod_class,
.clkdm_name = l4per_clkdm,
.main_clk = timer4_gfclk_mux,
.prcm = {
--
2.1.4
Re: [PATCH 1/2] ARM: DRA7: hwmod: Add data for GPTimers 13 through 16
On Mon, 16 Mar 2015, Suman Anna wrote: Add the hwmod data for GPTimers 13, 14, 15 and 16. All these timers are present in the L4PER3 clock domain. The corresponding DT nodes are already present but disabled. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 96 +++ 1 file changed, 96 insertions(+) Thanks, queued for v4.1. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
