Re: [PATCH] omap2+: add drm device

[Clark, Rob]

On Thu, May 24, 2012 at 12:01 AM, Tomi Valkeinen  wrote:
> Hi,
>
> On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
>> Register OMAP DRM/KMS platform device.  DMM is split into a
>> separate device using hwmod.
>>
>> Signed-off-by: Andy Gross 
>
> 
>
>> +static int __init omap_init_drm(void)
>> +{
>> +     struct omap_hwmod *oh = NULL;
>> +     struct platform_device *pdev;
>> +
>> +     /* lookup and populate the DMM information, if present - OMAP4+ */
>> +     oh = omap_hwmod_lookup("dmm");
>> +
>> +     if (oh) {
>> +             pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
>> +                                     false);
>> +             WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
>> +                     oh->name);
>> +     }
>> +
>> +     return platform_device_register(&omap_drm_device);
>> +
>> +}
>
> I still don't like fixing the tiler to drm. I would like to have basic
> tiler support in omapfb also, but with this approach I'll need to
> duplicate the code. And even if we disregard omapfb, wouldn't it be
> architecturally better to have the tiler as a separate independent
> library/driver?

Not easily, at least not if we want to manage to use tiler/dmm in a
more dynamic way, or to enable some additional features which are
still on the roadmap (like reprogramming dmm synchronized w/ scanout,
or some things which are coming if future hw generations).  We need
one place to keep track of which buffers are potentially evictable to
make room for mapping a new buffer.  And if you look at the tricks
that go on with mmap'ing tiled buffers to userspace, you *really*
don't want to duplicate that in N different drivers.

Fortunately with dmabuf there is not really a need for N different
drivers to need to use tiler/dmm directly.  The dmabuf mechanism
provides what they need to import GEM buffers from omapdrm.  That may
not really help omapfb because fbdev doesn't have a concept of
importing buffers.  But OTOH this is unnecessary, because drm provides
an fbdev interface for legacy apps.  The best thing I'd recommend is,
if you miss some features of omapfb in the drm fbdev implementation,
is to send some patches to add this missing features.

>> +struct omap_drm_platform_data {
>> +     struct omap_kms_platform_data *kms_pdata;
>> +};
>
> This one is missing struct omap_dmm_platform_data *dmm_pdata, so you
> didn't just move the struct. Is that on purpose?

the dmm pdata is no longer needed because we get what we need from
hwmod via platform_get_resource()

BR,
-R

>  Tomi
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] omap2+: add drm device

[Tomi Valkeinen]

Hi,

On Wed, 2012-05-23 at 15:08 -0500, Andy Gross wrote:
> Register OMAP DRM/KMS platform device.  DMM is split into a
> separate device using hwmod.
> 
> Signed-off-by: Andy Gross 



> +static int __init omap_init_drm(void)
> +{
> + struct omap_hwmod *oh = NULL;
> + struct platform_device *pdev;
> +
> + /* lookup and populate the DMM information, if present - OMAP4+ */
> + oh = omap_hwmod_lookup("dmm");
> +
> + if (oh) {
> + pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
> + false);
> + WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
> + oh->name);
> + }
> +
> + return platform_device_register(&omap_drm_device);
> +
> +}

I still don't like fixing the tiler to drm. I would like to have basic
tiler support in omapfb also, but with this approach I'll need to
duplicate the code. And even if we disregard omapfb, wouldn't it be
architecturally better to have the tiler as a separate independent
library/driver?

> +struct omap_drm_platform_data {
> + struct omap_kms_platform_data *kms_pdata;
> +};

This one is missing struct omap_dmm_platform_data *dmm_pdata, so you
didn't just move the struct. Is that on purpose?

 Tomi



signature.asc
Description: This is a digitally signed message part

Re: [PATCH v3 08/10] arm: omap4panda: Add support for omap4iss camera

[Sergio Aguirre]

Hi Tony,

On Tue, May 8, 2012 at 6:46 PM, Tony Lindgren  wrote:
> * Sergio Aguirre  [120502 08:21]:
>> This adds support for camera interface with the support for
>> following sensors:
>>
>> - OV5640
>> - OV5650
>
> It seems that at this point we should initialize new things like this
> with DT only. We don't quite yet have the muxing in place, but I'd
> rather not add yet another big platform_data file for something that
> does not even need to be there for DT booted devices.

Ok.

I'll look at that.

By the way, I've been very out of the loop on al DT related development..

Are these instructions valid for current master k.org branch?

http://omappedia.org/wiki/Device_Tree#Booting_with_DT_blob

Regards,
Sergio

>
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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: MFD USB host: prevents CORE retention in idle

[Kevin Hilman]

On 05/23/2012 05:01 PM, Kevin Hilman wrote:

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention
in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle,
thus preventing CORE from hitting retention.

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and
was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I
would've expected that runtime PM would've kicked in and shutdown this
clock.

Any ideas what's going on here?  Is this expected behavior?



If it helps, attached is a bootlog after enabling debug for 
mfd/omap-usb-host.c as well.  Notice there's a couple of clock-related 
warnings from this driver as well.  Not sure if they're relevant:


usbhs_omap: alias fck already exists
usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed error:-22

With debug enabled, I see the runtime resume during init followed by the 
runtime suspend.


[0.936248] usbhs_omap usbhs_omap: xclk60mhsp2_ck set parentfailed 
error:-22

[0.944152] usbhs_omap usbhs_omap: starting TI HSUSB Controller
[0.944335] usbhs_omap usbhs_omap: usbhs_runtime_resume
[0.944641] usbhs_omap usbhs_omap: OMAP UHH_REVISION 0x10
[0.944641] usbhs_omap usbhs_omap: OMAP3 ES version > ES2.1
[0.944671] usbhs_omap usbhs_omap: UHH setup done, 
uhh_hostconfig=8000121d

[0.947082] usbhs_omap usbhs_omap: usbhs_runtime_suspend

However, later in the boot I see a runtime_resume and never see another 
suspend.  That seems to be the root cause of CORE not hitting retention.


From the boot log:

[2.018707] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[2.025787] ehci_hcd: block sizes: qh 64 qtd 96 itd 160 sitd 96
[2.026306] ehci-omap ehci-omap.0: failed to get ehci port1 regulator
[2.026519] usbhs_omap usbhs_omap: usbhs_runtime_resume
[3.030639] ehci-omap ehci-omap.0: phy reset operation timed out
[3.030700] ehci-omap ehci-omap.0: reset hcs_params 0x1313 dbg=0 cc=1 
pcc=3 ordered ports=3
[3.030731] ehci-omap ehci-omap.0: reset hcc_params 0016 thresh 1 
uframes 256/512/1024 park
[3.030761] ehci-omap ehci-omap.0: reset command 0080b02  park=3 
ithresh=8 period=1024 Reset HALT

[3.030792] ehci-omap ehci-omap.0: OMAP-EHCI Host Controller

Since the only get/puts I see are in omap_usbhs_init(), I'm not sure how 
this driver is being runtime resumed.  Presumably it's due to how the 
rest of the USB stack works, which I'm not at all familiar with.


Hopefully, the above is enough to debug the problem,

Thanks,

Kevin
[0.00] Booting Linux on physical CPU 0
[0.00] Linux version 3.4.0-rc7-pm+debug+initramfs-01073-g0ecc382-dirty 
(khilman@paris) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #20 SMP Wed 
May 23 17:10:56 PDT 2012
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing 
instruction cache
[0.00] Machine: Gumstix Overo
[0.00] bootconsole [earlycon0] enabled
[0.00] Memory policy: ECC disabled, Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c09c0dc0, node_mem_map 
c0f1e000
[0.00]   Normal zone: 512 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 64768 pages, LIFO batch:15
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[0.00] Clocking rate (Crystal/Core/MPU): 26.0/331/500 MHz
[0.00] PERCPU: Embedded 9 pages/cpu @c1124000 s12992 r8192 d15680 u36864
[0.00] pcpu-alloc: s12992 r8192 d15680 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 64768
[0.00] Kernel command line: console=ttyO2,115200n8 earlyprintk 
ip=192.168.1.157:192.168.1.5:192.168.1.254:255.255.255.0:overo:eth0:none 
root=/dev/nfs 
nfsroot=192.168.1.236:/opt/kjh/rootfs/debian/armel,rsize=4096,wsize=409
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 255MB = 255MB total
[0.00] Memory: 243328k/243328k available, 18816k reserved, 0K highmem
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xd080 - 0xff00   ( 744 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc066da70   (6551 kB)
[ 

MFD USB host: prevents CORE retention in idle

[Kevin Hilman]

Hi Keshava,

Using current l-o master, I noticed that CORE was not hitting retention
in idle on my 3530/Overo.  CORE hits retention on suspend just fine.

Debugging this, I found that usbtll_fck was still enabled during idle,
thus preventing CORE from hitting retention.

To test, I disabled USB host (CONFIG_MFD_OMAP_USB_HOST=n in .config) and
was then started seeing CORE hit retention in idle again.

I have nothing plugged into the USB host port on this board, so I
would've expected that runtime PM would've kicked in and shutdown this
clock.

Any ideas what's going on here?  Is this expected behavior?

Kevin
--
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] OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup

[Kevin Hilman]

"Govindraj.R"  writes:

> From: "Govindraj.R" 
>
> The commit (bce492c0  ARM: OMAP2+: UART: Fix incorrect population of
> default uart pads) removed default uart pads that where getting populated
> and which was making rx pin wakeup capable. If uart pads were used in
> different mode by any other module then it would fail since the default
> pads took over all the uart pins forcefully. With removal of default pads
> the rx_pad wakeup for console uart while waking up from off mode is broken.
>
> Utilise the mux api available to probe the availability of mux pins
> in uart mode and probe for availability of uart pin in mux mode0
> if uart is available as uart pin itself then configure rx pin
> as wakeup capable.
>
> This patch itself doesn't cater to all boards. Boards using uart rx wakeup
> mechanism should ensure the usage of omap_serial_init_port by configuring
> required uart ports and pass necessary mux data, till then this probing of
> uart pins can cater to enabling of rx pad wakeup to most of the boards.
>
> This patch can also throw some boot warning from _omap_mux_get_by_name
> if pin is requested for availability is not present while dynamically probing
> the uart pins availability such boot warnings can be addressed only when board
> files are patched with omap_serial_init_port calls passing the right pads
> needed for a given port.
>
> Discussion Threads for reference:
> http://www.spinics.net/lists/linux-omap/msg69859.html
> http://www.spinics.net/lists/linux-omap/msg68659.html
>
> Cc: Felipe Balbi 
> Cc: Kevin Hilman 
> Cc: Russ Dill 
> Cc: Tony Lindgren 
> Cc: Paul Walmsley 
> Cc: Ameya Palande 
> Signed-off-by: Govindraj.R 

Tony, it's up to you if you're OK with this mux interface, but I can at
least confirm that this gets runtime PM + UART wakeups working again on
the boards I tried: 3530/Overo, 3430/n900, 3530/OMAP3EVM.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] OMAP: mailbox initial device tree support

[Omar Ramirez Luna]

Hi Tony, Benoit,

On 1 May 2012 12:47, Omar Ramirez Luna  wrote:
> To allow mailbox driver to function with device tree.
>
> Tested in OMAP4 and OMAP3. OMAP2 untested.
>
> Omar Ramirez Luna (2):
>  OMAP: mailbox: add device tree support
>  arm/dts: OMAP2+: Add mailbox nodes
>
>  .../devicetree/bindings/arm/omap/mailbox.txt       |    9 +
>  arch/arm/boot/dts/omap2.dtsi                       |    5 +
>  arch/arm/boot/dts/omap3.dtsi                       |    5 +
>  arch/arm/boot/dts/omap4.dtsi                       |    5 +
>  arch/arm/mach-omap2/devices.c                      |    3 +++
>  arch/arm/mach-omap2/mailbox.c                      |   12 
>  6 files changed, 39 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/omap/mailbox.txt

Can you share your thoughts for these patches?

Regards,

Omar
--
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] omap2+: add drm device

[Andy Gross]

Register OMAP DRM/KMS platform device.  DMM is split into a
separate device using hwmod.

Signed-off-by: Andy Gross 
---
 arch/arm/mach-omap2/Makefile   |4 ++
 arch/arm/mach-omap2/drm.c  |   61 
 drivers/staging/omapdrm/omap_drv.h |2 +-
 drivers/staging/omapdrm/omap_priv.h|   55 
 include/linux/platform_data/omap_drm.h |   52 +++
 5 files changed, 118 insertions(+), 56 deletions(-)
 create mode 100644 arch/arm/mach-omap2/drm.c
 delete mode 100644 drivers/staging/omapdrm/omap_priv.h
 create mode 100644 include/linux/platform_data/omap_drm.h

diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 49f92bc..c301ab7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -187,6 +187,10 @@ ifneq ($(CONFIG_TIDSPBRIDGE),)
 obj-y  += dsp.o
 endif
 
+ifneq ($(CONFIG_DRM_OMAP),)
+obj-y  += drm.o
+endif
+
 # Specific board support
 obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o
 obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mach-omap2/drm.c
new file mode 100644
index 000..72e0f01b
--- /dev/null
+++ b/arch/arm/mach-omap2/drm.c
@@ -0,0 +1,61 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct platform_device omap_drm_device = {
+   .dev = {
+   .coherent_dma_mask = DMA_BIT_MASK(32),
+   },
+   .name = "omapdrm",
+   .id = 0,
+};
+
+static int __init omap_init_drm(void)
+{
+   struct omap_hwmod *oh = NULL;
+   struct platform_device *pdev;
+
+   /* lookup and populate the DMM information, if present - OMAP4+ */
+   oh = omap_hwmod_lookup("dmm");
+
+   if (oh) {
+   pdev = omap_device_build(oh->name, -1, oh, NULL, 0, NULL, 0,
+   false);
+   WARN(IS_ERR(pdev), "Could not build omap_device for %s\n",
+   oh->name);
+   }
+
+   return platform_device_register(&omap_drm_device);
+
+}
+
+arch_initcall(omap_init_drm);
+
+#endif
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index b7e0f07..96296e0 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -25,8 +25,8 @@
 #include 
 #include 
 #include 
+#include 
 #include "omap_drm.h"
-#include "omap_priv.h"
 
 #define DBG(fmt, ...) DRM_DEBUG(fmt"\n", ##__VA_ARGS__)
 #define VERB(fmt, ...) if (0) DRM_DEBUG(fmt, ##__VA_ARGS__) /* verbose debug */
diff --git a/drivers/staging/omapdrm/omap_priv.h 
b/drivers/staging/omapdrm/omap_priv.h
deleted file mode 100644
index ef64414..000
--- a/drivers/staging/omapdrm/omap_priv.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/*
- * include/drm/omap_priv.h
- *
- * Copyright (C) 2011 Texas Instruments
- * Author: Rob Clark 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
- */
-
-#ifndef __OMAP_PRIV_H__
-#define __OMAP_PRIV_H__
-
-/* Non-userspace facing APIs
- */
-
-/* optional platform data to configure the default configuration of which
- * pipes/overlays/CRTCs are used.. if this is not provided, then instead the
- * first CONFIG_DRM_OMAP_NUM_CRTCS are used, and they are each connected to
- * one manager, with priority given to managers that are connected to
- * detected devices.  Remaining overlays are used as video planes.  This
- * should be a good default behavior for most cases, but yet there still
- * might be times when you wish to do something different.
- */
-stru

Re: rx51: support for lis3lv02d accelerometer

[Pali Rohár]

On Monday 21 May 2012 09:08:40 Tony Lindgren wrote:
> Hi Pali,
>
> * Tony Lindgren  [120508 17:12]:
> > * Pali Rohár  [120504 08:41]:
> > > Hi!
> > >
> > > Upstream linux kernel has already driver for lis3lv02d
> > > accelerometer in drivers/misc/lis3lv02d. So now can be
> > > added also platform support for nokia rx51. Patch exists
> > > for long time in meego obs repository:
> > > https://build.pub.meego.com/package/view_file?file=linux-2
> > > .6-omap-rx51-Platform-support-for-lis3lv02d-acceleromet.pat
> > > ch&package=kernel-adaptation-n900&project�%3AAdaptation%3
> > > AN900
> > >
> > > It is possible to include this patch to upstream kernel?
> >
> > Thanks, applying into board branch with From: Ameya as in the
> > link above.
>
> Just noticed that this one is still using OMAP_GPIO_IRQ that
> won't work any longer. Can you please send a fix on top of this
> patch against linux next to fix it?
>
> The fix is to use gpio_to_irq() in the related init function
> instead of static OMAP_GPIO_IRQ in the data structure.
>
> Regards,
>
> Tony

Sorry, but now I do not have time for it. Tony, if fix is simple
can you do it?

--
Pali Rohár
pali.ro...@gmail.com

signature.asc
Description: This is a digitally signed message part.

Re: [PATCH v5 1/4] regulator: helper routine to extract regulator_init_data

[David Brown]

On Fri, Nov 18, 2011 at 04:47:17PM +0530, Rajendra Nayak wrote:

> + xyzreg: regulator@0 {
> + regulator-min-microvolt = <100>;
> + regulator-max-microvolt = <250>;
> + regulator-always-on;
> + vin-supply = <&vin>;
> + };

Just noticed this, but the '@0' shouldn't be on the name, since there
isn't a reg attribute on this node.  Perhaps it should be
"regulator-xyz"?

David

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

[Hiremath, Vaibhav]

On Wed, May 23, 2012 at 20:38:27, Paul Walmsley wrote:
> Hi Vaibhav
> 
> On Wed, 23 May 2012, Hiremath, Vaibhav wrote:
> 
> > I used your cleaned version of clocktree data, where you have removed all 
> > leaf-nodes and merged multiple clocks nodes into one; but it did not work. 
> > I 
> > attempted to review the cleanup and tried to debug, but found it bit hard 
> > to 
> > come back to working clocktree from stripped version. So moved back to my 
> > submitted clocktree and started stripping the clock leaf-nodes, same way 
> > you 
> > had done it. Now I reached to the stage where I have working clocktree 
> > without peripheral leaf-nodes and booting on BeagleBone.
> 
> Okay great, please post that to the list so we can diff it against the 
> version that I did, and also so we can queue it for merging in 3.6?
> 

Just doing final round of review and cleanup...may be by tomorrow, I should 
be able to submit it (without common-clock framework).


> > Just FYI (may need your help), I got into some issues (still open) during 
> > this cleanup -
> > 
> > 1. In cases where we have clock selection option for node-leafs, like, 
> >Timers, I removed enable_reg entry from the node, which results into a 
> >kernel error message from function omap2_dflt_clk_disable()
> > 
> > clock: clk_disable called on independent clock %s which has no enable_reg
> 
> Shouldn't those clocks use clkops_null then?
> 
> > 2. clkdm_name entry: 
> >The issue is, two entries available for clockdomain associated for 
> >module/clock 
> > - hwmod_data.main_clk and 
> > - clk.clkdm_name
> > 
> >They must match, right? The parent/root clocks flows from one domain to 
> >another domain, so I have to keep the nodes just for sake of matching 
> >clockdomain entry present in associated main_clk data.
> > 
> >I am still reviewing the code from Rajendra, but one of Rajendra's patch 
> >actually will help here, made it to use hwmod_data.clkdm (if available) 
> >always, instead of directly using clk.clkdm.
> 
> Well because of this CLKDIV32K snafu, we'll need to keep the clock 
> framework-based clockdomain control for AM33xx, at the very least for 
> the CLKDIV32K clock.
> 
> I'd suggest starting with specifying a clockdomain name for each clock.  
> If nothing else, this should help think through the power management 
> behavior for each clock.  Then those can be easily removed later with a 
> simple grep.
> 
> > 3. If I understand correctly, hwmod_data.main_clk is functional clock and   
> >  
> >hwmod_ocp_if.clk is interface clock, right?
> 
> Basically, yes.  To be more precise, in cases where 
> modules have multiple functional clocks, hwmod_data.main_clk is the 
> functional clock that is needed in order for register reads and writes to 
> the IP block to succeed.
> 

I believe register read/write to IP block is depends on only interface 
Clocks? Atleast in case of OMAP3, it was like that, right??


Another issues is, 

I came across situation where, two modules fall into different clock domains 
but their functional clock is happened to be coming from same 
source/dpll-divider. So in order to satisfy clkdm match between them, I have
kept nodes without enable_regs.



> >So currently, I have mentioned same entry in both the places (especially 
> >for Peripherals/modules).
> >I am planning to remove ocp_if/clk entry data for all modules..
> 
> Hmmm, could you explain this further?
> 

what if, module only has interface clock? Should it be present as main_clk or 
ocp_if.clk or both??
Example would be, TPCC, TPTC, smartreflex, etc...

Thanks,
Vaibhav

> Every ocp_if structure that you create should have an interface clock 
> specified.  And almost all of your hwmods should have a main_clk 
> specified.
> 
> 
> - Paul
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH-V3 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

[Paul Walmsley]

Hi Vaibhav

On Wed, 23 May 2012, Hiremath, Vaibhav wrote:

> I used your cleaned version of clocktree data, where you have removed all 
> leaf-nodes and merged multiple clocks nodes into one; but it did not work. I 
> attempted to review the cleanup and tried to debug, but found it bit hard to 
> come back to working clocktree from stripped version. So moved back to my 
> submitted clocktree and started stripping the clock leaf-nodes, same way you 
> had done it. Now I reached to the stage where I have working clocktree 
> without peripheral leaf-nodes and booting on BeagleBone.

Okay great, please post that to the list so we can diff it against the 
version that I did, and also so we can queue it for merging in 3.6?

> Just FYI (may need your help), I got into some issues (still open) during 
> this cleanup -
> 
> 1. In cases where we have clock selection option for node-leafs, like, 
>Timers, I removed enable_reg entry from the node, which results into a 
>kernel error message from function omap2_dflt_clk_disable()
> 
> clock: clk_disable called on independent clock %s which has no enable_reg

Shouldn't those clocks use clkops_null then?

> 2. clkdm_name entry: 
>The issue is, two entries available for clockdomain associated for 
>module/clock 
> - hwmod_data.main_clk and 
> - clk.clkdm_name
> 
>They must match, right? The parent/root clocks flows from one domain to 
>another domain, so I have to keep the nodes just for sake of matching 
>clockdomain entry present in associated main_clk data.
> 
>I am still reviewing the code from Rajendra, but one of Rajendra's patch 
>actually will help here, made it to use hwmod_data.clkdm (if available) 
>always, instead of directly using clk.clkdm.

Well because of this CLKDIV32K snafu, we'll need to keep the clock 
framework-based clockdomain control for AM33xx, at the very least for 
the CLKDIV32K clock.

I'd suggest starting with specifying a clockdomain name for each clock.  
If nothing else, this should help think through the power management 
behavior for each clock.  Then those can be easily removed later with a 
simple grep.

> 3. If I understand correctly, hwmod_data.main_clk is functional clock and
>hwmod_ocp_if.clk is interface clock, right?

Basically, yes.  To be more precise, in cases where 
modules have multiple functional clocks, hwmod_data.main_clk is the 
functional clock that is needed in order for register reads and writes to 
the IP block to succeed.

>So currently, I have mentioned same entry in both the places (especially 
>for Peripherals/modules).
>I am planning to remove ocp_if/clk entry data for all modules..

Hmmm, could you explain this further?

Every ocp_if structure that you create should have an interface clock 
specified.  And almost all of your hwmods should have a main_clk 
specified.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc

[Paul Walmsley]

On Tue, 22 May 2012, Tony Lindgren wrote:

> * Paul Walmsley  [120521 23:51]:
> > 
> > Next, I'd suggest implementing the code to allow GPMC timing configuration 
> > from raw register data (the second method above).  This is hackish but for 
> > some boards, this is all we'll have.  This will also presumably require 
> > some extra DT bindings for the register data.  If this method is used, 
> > this code should also call a PM function to block clock rate changes on 
> > the GPMC clock, and an explanatory warning should be logged to the 
> > console.
> 
> Also something to note here is that generating dynamic timings from the
> fixed GPMC register values won't work for other frequencies.
> 
> As far as I remember, the main problem trying to convert fixed value
> GPMC timings into dynamic timings is the fact that some GPMC values
> calculated depend on clock cycles, while other values depend on time.
> 
> So the cycle values remain unknown trying to upsample from fixed timings.

Yep indeed.  That's why clock rate changes have to be blocked on the GPMC 
clock.  If we don't have GPMC clock rate-independent timing data, then 
I think we'll have to keep the GPMC clock rate fixed.

> > For boards that we don't have access to, and all someone would have are 
> > the register values set by the bootloader, I'd propose a phased approach:
> > 
> > 1. The kernel should log the bootloader-provided GPMC timing registers to 
> > the console during boot, along with a warning message that indicates that 
> > GPMC for these boards will cease to function in the near future unless 
> > patches are provided to update the kernel board file and/or DT data with 
> > the GPMC register contents.  This should allow people who have those 
> > boards and who care about them to submit kernel patches to allow the 
> > GPMC-attached devices to continue to function.
> 
> Unfortunately for many of the older boards these values will probably
> remain unknown.
> 
> So the better approach here is to just disable frequency scaling
> for these cases. Otherwise we'll be breaking old boards with smsc911x
> where the timings for the FPGA controlling smsc911x are unknown.
> 
> If we somehow manage to get those values without breaking support for
> these boards, then yes I agree we should deprecate hardcoded and
> bootloader values.

I was thinking that if we log the register values supplied by the 
bootloader to the console, then someone can write a patch to the board 
file or DT data to set those register values explicitly in the kernel, 
once they're known.  Or at least just report them to the l-o list.

So then that should reduce the problem cases down to boards which no one 
reports the data to the mailing list within a few mainline kernel releases 
-- i.e., boards which are unmaintained.  For those boards, I'd suggest 
that we just drop GPMC support until someone shows up who has a board and 
can test-boot it.  Or just drop the board completely ;-)


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-pm] [PATCH V3 00/10] PM: Create the AVS(Adaptive Voltage Scaling)

[Menon, Nishanth]

On Wed, May 9, 2012 at 1:29 PM, Kevin Hilman  wrote:
> "Woodruff, Richard"  writes:
>
>>> From: Hilman, Kevin
>>> Sent: Tuesday, May 08, 2012 5:17 PM
>>
>>> A basic OMAP AVS driver has been in mainline for a long time, yet we
>>> have not seen support submitted for all of these features.
>>
>> 1.5/3.5 is a feature.
>
> And I'm still waiting for it to be submitted upstream.
>
>> ABB is requirement for a production useable driver. Higher speed rated
>> OMAP4 and all OMAP5 added these to be useable.
>
> ditto
>
>> Yes this is effort. Point of mentioning is to raise awareness of need.
>
> I'm well aware of the need.
>
>> Yet to be added feature has different meaning than functional gap.
>
> And both need to be submitted upstream.

SR 1.5: http://marc.info/?l=linux-omap&m=129933897910785&w=2
ABB: http://marc.info/?l=linux-omap&m=130939399209099&w=2

I am not sure what you mean "need to be submitted upstream"?

Just tired of seeing things perpetually change without considering
even how to handle features that are mandatory for SoC even with code
posted upstream to show exactly what it takes.. I think you do mean
merged upstream in this context.


Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/7] remoteproc: resource table overhaul

[Ohad Ben-Cohen]

Hi Ludovic,

On Tue, May 22, 2012 at 3:51 PM, frq09524  wrote:
> In my previous patch, to find the correct subdevice that match with physical 
> memory, I used pa member of rproc_mem_entry.

I'm not sure we want to find these subdevices using the physical
memory of the expected region.

Doing so means more work when setting up those numbers initially, and
may also break if/when those number changes.

What do you think about looking up those subdevices by names?

E.g. before allocating the vrings, we may look for a subdevice called
"vrings-mem". If one exists, we'll use it when invoking the DMA API.
If not, we'll just use the default rproc device.

This way we don't need to change the firmware if/when we change the
memory regions allocated for each purpose.

Thanks,
Ohad.
--
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 3/3] ARM: OMAP3+: clock33xx: Add AM33XX clock tree data

[Hiremath, Vaibhav]

On Wed, Apr 25, 2012 at 21:06:43, Paul Walmsley wrote:
> On Wed, 25 Apr 2012, Cousson, Benoit wrote:
> 
> > Please take care of changing the hwmod main_clk as well. But maybe 
> > that's not part of that series.
> 
> It's not part of the series yet.
> 
> Vaibhav, could you take care of changing the main_clk in your hwmod data 
> patches, and send those to the list?
> 
> 

Paul,

Just an update on the status,

I used your cleaned version of clocktree data, where you have removed all 
leaf-nodes and merged multiple clocks nodes into one; but it did not work. I 
attempted to review the cleanup and tried to debug, but found it bit hard to 
come back to working clocktree from stripped version. So moved back to my 
submitted clocktree and started stripping the clock leaf-nodes, same way you 
had done it. Now I reached to the stage where I have working clocktree 
without peripheral leaf-nodes and booting on BeagleBone.

I will start working on migrating to common clock framework now, and hoping 
to finish it soon.


Just FYI (may need your help), I got into some issues (still open) during 
this cleanup -


1. In cases where we have clock selection option for node-leafs, like, 
   Timers, I removed enable_reg entry from the node, which results into a 
   kernel error message from function omap2_dflt_clk_disable()

clock: clk_disable called on independent clock %s which has no enable_reg


2. clkdm_name entry: 
   The issue is, two entries available for clockdomain associated for 
   module/clock 
- hwmod_data.main_clk and 
- clk.clkdm_name

   They must match, right? The parent/root clocks flows from one domain to 
   another domain, so I have to keep the nodes just for sake of matching 
   clockdomain entry present in associated main_clk data.

   I am still reviewing the code from Rajendra, but one of Rajendra's patch 
   actually will help here, made it to use hwmod_data.clkdm (if available) 
   always, instead of directly using clk.clkdm.

3. If I understand correctly, hwmod_data.main_clk is functional clock and
   hwmod_ocp_if.clk is interface clock, right?

   So currently, I have mentioned same entry in both the places (especially 
   for Peripherals/modules).
   I am planning to remove ocp_if/clk entry data for all modules..
   

Thanks,
Vaibhav
--
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] iommu/core: pass a user-provided token to fault handlers

[Joerg Roedel]

On Mon, May 21, 2012 at 08:20:05PM +0300, Ohad Ben-Cohen wrote:
> Sometimes a single IOMMU user may have to deal with several
> different IOMMU devices (e.g. remoteproc).
> 
> When an IOMMU fault happens, such users have to regain their
> context in order to deal with the fault.
> 
> Users can't use the private fields of neither the iommu_domain nor
> the IOMMU device, because those are already used by the IOMMU core
> and low level driver (respectively).
> 
> This patch just simply allows users to pass a private token (most
> notably their own context pointer) to iommu_set_fault_handler(),
> and then makes sure it is provided back to the users whenever
> an IOMMU fault happens.
> 
> The patch also adopts remoteproc to the new fault handling
> interface, but the real functionality using this (recovery of
> remote processors) will only be added later in a subsequent patch
> set.
> 
> Cc: Fernando Guzman Lugo 
> Signed-off-by: Ohad Ben-Cohen 

Applied, thanks.


-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
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