Re: [PATCH] omap_vout: Set DSS overlay_info only if paddr is non zero
On Mon, Mar 19, 2012 at 5:16 PM, Archit Taneja a0393...@ti.com wrote:
On Monday 19 March 2012 02:15 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 16, 2012 at 16:41:27, Taneja, Archit wrote:
Hi,
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info using
set_overlay_info()
when the physical address for the overlay is still not configured.
This happens
in omap_vout_probe() and vidioc_s_fmt_vid_out().
The calls to omapvid_init(which internally calls set_overlay_info())
are removed
from these functions. They don't need to be called as the
omap_vout_device
struct anyway maintains the overlay related changes made. Also,
remove the
explicit call to set_overlay_info() in vidioc_streamon(), this was
used to set
the paddr, this isn't needed as omapvid_init() does the same thing
later.
These changes are required as the DSS2 driver since 3.3 kernel
doesn't let you
set the overlay info with paddr as 0.
Signed-off-by: Archit Tanejaarc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 36
-
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1fb7d5b..dffcf66 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1157,13 +1157,6 @@ static int vidioc_s_fmt_vid_out(struct file
*file, void *fh,
/* set default crop and win */
omap_vout_new_format(vout-pix,vout-fbuf,vout-crop,vout-win);
- /* Save the changes in the overlay strcuture */
- ret = omapvid_init(vout, 0);
- if (ret) {
- v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
- goto s_fmt_vid_out_exit;
- }
-
ret = 0;
s_fmt_vid_out_exit:
@@ -1664,20 +1657,6 @@ static int vidioc_streamon(struct file *file,
void *fh, enum v4l2_buf_type i)
omap_dispc_register_isr(omap_vout_isr, vout, mask);
- for (j = 0; j ovid-num_overlays; j++) {
- struct omap_overlay *ovl = ovid-overlays[j];
-
- if (ovl-manager ovl-manager-device) {
- struct omap_overlay_info info;
- ovl-get_overlay_info(ovl,info);
- info.paddr = addr;
- if (ovl-set_overlay_info(ovl,info)) {
- ret = -EINVAL;
- goto streamon_err1;
- }
- }
- }
-
Have you checked for build warnings? I am getting build warnings
CC drivers/media/video/omap/omap_vout.o
CC drivers/media/video/omap/omap_voutlib.o
CC drivers/media/video/omap/omap_vout_vrfb.o
drivers/media/video/omap/omap_vout.c: In function 'vidioc_streamon':
drivers/media/video/omap/omap_vout.c:1619:25: warning: unused variable
'ovid'
drivers/media/video/omap/omap_vout.c:1615:15: warning: unused variable
'j'
LD drivers/media/video/omap/omap-vout.o
LD drivers/media/video/omap/built-in.o
Can you fix this and submit the next version?
I applied the patch on the current mainline kernel, it doesn't give any
build warnings. Even after applying the patch, 'j and ovid' are still
used in vidioc_streamon().
Can you check if it was applied correctly?
Archit,
I could able to trace what's going on here,
I am using v4l_for_linus branch, which has one missing patch,
commit aaa874a985158383c4b394c687c716ef26288741
Author: Tomi Valkeinentomi.valkei...@ti.com
Date: Tue Nov 15 16:37:53 2011 +0200
OMAPDSS: APPLY: rewrite overlay enable/disable
So, I do not have below changes,
@@ -1686,6 +1681,16 @@ static int vidioc_streamon(struct file *file, void
*fh, enum v4l2_buf_type i)
if (ret)
v4l2_err(vout-vid_dev-v4l2_dev, failed to change
mode\n);
+ for (j = 0; j ovid-num_overlays; j++) {
+ struct omap_overlay *ovl = ovid-overlays[j];
+
+ if (ovl-manager ovl-manager-device) {
+ ret = ovl-enable(ovl);
+ if (ret)
+ goto streamon_err1;
+ }
+ }
+
This explains why I am seeing these warnings. Let me give pull request
based on master branch.
Okay. Thanks for looking into this.
Archit
Hi Vaibhav,
This patch has been outstanding since March, and we have received
reports from various users. Could you please push it ASAP to Mauro for
the upcoming -rc?
Or Did I miss a pull request from you containing this?
Thanks and best regards,
~Sumit.
Thanks,
Vaibhav
Regards,
Archit
Will fix this and submit.
Archit
Thanks,
Vaibhav
/* First save the configuration in ovelray structure */
ret = omapvid_init(vout, addr);
if (ret)
@@ -2071,11 +2050,12 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
}
video_set_drvdata(vfd, vout);
- /* Configure the overlay structure */
- ret = omapvid_init(vid_dev-vouts[k], 0);
- if (!ret)
- goto success;
+ dev_info(pdev-dev, : registered and initialized
+ video device %d\n, vfd-minor);
+ if (k
Re: [PATCH] omap dss2: fix specification spelling in Kconfig
On Wed, 2012-06-27 at 22:09 +0200, Peter Meerwald wrote: Signed-off-by: Peter Meerwald pme...@pmeerw.net --- drivers/video/omap2/dss/Kconfig |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Thanks, applied to omapdss tree. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v2] arm: omap3: am35x: Fix clockdomain dependencies
On Thu, 19 Apr 2012, Mark A. Greer wrote: From: Mark A. Greer mgr...@animalcreek.com The am35x family of SoCs do not have an IVA so a parallel set of clockdomain dependencies are required that are simililar to OMAP3 but without any IVA dependencies. Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- Paul, this is a respin of [PATCH 08/12] arm: omap3: am35x: Fix clockdomain dependencies with your comments [hopefully] addressed. I'm breaking that long series into smaller pieces because most of them really weren't related. Thanks, queued for 3.6. - 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: v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle
+ Shubro, Felipe, On Thu, Jun 28, 2012 at 12:57 AM, Paul Walmsley p...@pwsan.com wrote: On Wed, 27 Jun 2012, Paul Walmsley wrote: Looks like something broke between v3.5-rc3 and v3.5-rc4 with dynamic idle on 3530ES3 Beagle. 37xx EVM doesn't seem to be affected. Taking a closer look now. Reverting commit 91930652a23de0873a157aa1d9962cb878d64451 (OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup) makes wakeup from dynamic retention idle work again. I suspected this. This could be because, all the board are now expected to setup the pin configurations. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: EHCI: Fix the hub disconnect after resume
On Wed, Jun 27, 2012 at 7:54 PM, Alan Stern st...@rowland.harvard.edu wrote:
On Wed, 27 Jun 2012, Keshava Munegowda wrote:
Its observed that in Beagle XM , during suspend/resume the OMAP
EHCI controller losing the register contents. this is causing the
hub disconnect after the resume, this is causing failure of
device detection after the resume.
to avoid the hub disconnect , The ehci config flag register is
configured again , reset the phy and issue the port powers during
resume.
The idea is good, but the implementation is wrong.
+static int omap_ehci_bus_resume(struct usb_hcd *hcd)
+{
+
+ struct device *dev = hcd-self.controller;
+ struct ehci_hcd_omap_platform_data *pdata = dev-platform_data;
+ struct resource *regs = hcd-regs;
+
+ /* In case , ports are not powered and config flag not set */
+ if (~(ehci_read(regs, EHCI_CONFIGFLAG) 0x01)) {
+ ehci_write(regs, EHCI_CONFIGFLAG, 0x1);
+
+ /*
+ * An undocumented feature in the OMAP3 EHCI controller,
+ * causes suspended ports to be taken out of suspend when
+ * the USBCMD.Run/Stop bit is cleared (for example when
+ * we do ehci_bus_suspend).
+ * This breaks suspend-resume if the root-hub is allowed
+ * to suspend. Writing 1 to this undocumented register bit
+ * disables this feature and restores normal behavior.
+ */
+ ehci_write(regs, EHCI_INSNREG04,
+ EHCI_INSNREG04_DISABLE_UNSUSPEND);
+
+ /* Soft reset the PHY using PHY reset command over ULPI */
+ if (pdata-port_mode[0] == OMAP_EHCI_PORT_MODE_PHY)
+ omap_ehci_soft_phy_reset(dev, 0);
+ if (pdata-port_mode[1] == OMAP_EHCI_PORT_MODE_PHY)
+ omap_ehci_soft_phy_reset(dev, 1);
+
+ /* root ports should always stay powered */
+ ehci_port_power(hcd_to_ehci(hcd), 1);
+ }
This needs to be done in the resume routine, not the bus_resume
routine. Since ehci-omap doesn't have any suspend or resume routines,
it's not surprising that the controller doesn't work correctly after
the system is resumed.
In a couple of days I will submit a patch that will make it a lot
easier to add suspend and resume routines for EHCI platform drivers.
Maybe you'd prefer to wait until then to fix this issue.
Alan Stern
Thanks Alan
Ok, I will wait for your patches.
regards
keshava
--
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] OMAP System Control Module
Hello Konstantin, On Thu, Jun 28, 2012 at 7:43 AM, Eduardo Valentin eduardo.valen...@ti.com wrote: Hello, On Wed, Jun 27, 2012 at 10:04:32PM +0400, Konstantin Baydarov wrote: Hello. This is a next version of series of patches(based on Eduardo Valentin's patch set) adding a basic support for system control module, on OMAP4+ context. It is a working in progress. Main changes since previous patch set version: - Bandgap and usb phy: drivers are now independent from control module driver, they use their own functions to acess scm registers. Well, I believe the idea of having them with their own io resource was to avoid children drivers accessing each other io areas. Is this now working? - omap-control-core: resources aren't hardcoded, they are specified in dts file. - omap-control-core: Control module is a built-in driver - added control module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4. Probably, no configuration option is required! Why is this? I suppose the idea is to have the arch config selecting that flag. - omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows access of SCM registers very early, for example from omap_type() Is this going to be reserved as well? if yes, how children are going to have their own access functions? - omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control module device. - omap-control-core: removed omap_control_get, omap_control_readl, omap_control_writel fine, assuming the io split works... - omap-control-core: added omap_control_status_read that is used early in omap_type - Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers. - Bandgap: Check the type of bandgap dynamically in bandgap driver probe function by reading omap core control module revision register CONTROL_GEN_CORE_REVISION. this has some issue... I will post comment on the patch - Bandgap and usb phy: Parent SCM platform device IOMEM resources is used to get the base address of SCM window. Ohh.. Then what is the point of having them using their own io access functions, nothing is again protected as you have only 1 io resource which is shared. And now is even worse because you have several io access function.. I think this is moving backwards. - Bandgap masks defines were moved to drivers/thermal/omap-bandgap.c. TODO list for bandgap driver: - Reserve omap-control-core IOMEM window. - Improve thermal zone definition for OMAP4 - Introduce the thermal zones for OMAP5 Based on the review comments on RFC patch series, there are more things to be done. I have the O4 and O5 zone definition ready. But that work depends on generic CPU cooling patches. I have also looked the driver support for 4430. But the probing and io resource split is still based on previous design. I have also a patch which does the remapping in the bandgap driver. But really, for this to work it would require to have several entries in the reg property. And that is going to change from BG version to BG version. I can prepare some patches for this. You can find the updated patches here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/bandgap_clean But, as I said they are based on the generic cpu cooling. And the zone registration follows the API as in linux-next. -- Eduardo Valentin -- 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/7] OMAP2+: use control module mfd driver in omap_type
Hi,
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120627 11:09]:
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 00486a8..1b0cec8 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/mfd/omap_control.h
#include asm/cputype.h
@@ -43,13 +44,13 @@ int omap_type(void)
u32 val = 0;
if (cpu_is_omap24xx()) {
- val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
+ val = omap_control_status_read(OMAP24XX_CONTROL_STATUS);
} else if (cpu_is_am33xx()) {
- val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
+ val = omap_control_status_read(AM33XX_CONTROL_STATUS);
} else if (cpu_is_omap34xx()) {
- val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
+ val = omap_control_status_read(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
- val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ val = omap_control_status_read(OMAP4_CTRL_MODULE_CORE_STATUS);
} else {
pr_err(Cannot detect omap type!\n);
goto out;
I think you should keep the CONTROL_STATUS defines private to the
SCM core driver, there should be no need to pass it here. Just
make it int omap_control_status_read(void).
Of course that means that the SCM core is initialized to some extent
to know where to find the CONTROL_STATUS register. That should
probably be done as part of the set_globals calls done in init_early
in mach-omap2/io.c file.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: OMAP: omap2plus_defconfig: Enable EXT4 support
Hi, * Javier Martinez Canillas martinez.jav...@gmail.com [120627 15:32]: On Sun, Jun 24, 2012 at 12:18 AM, Javier Martinez Canillas jav...@dowhile0.org wrote: On OMAP boards that includes an SD card slot, an EXT4 partition could be used to store the root file system. So, the kernel should have built-in support for EXT4 to be able to mount the VFS root on boot. Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org --- arch/arm/configs/omap2plus_defconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 9854ff4..f3087cb 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -197,6 +197,7 @@ CONFIG_RTC_DRV_TWL4030=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y # CONFIG_EXT3_FS_XATTR is not set +CONFIG_EXT4_FS=y CONFIG_QUOTA=y CONFIG_QFMT_V2=y CONFIG_MSDOS_FS=y -- 1.7.7.6 Hi, any news about this patch? Is quite annoying to have to enable EXT4 support each time I want to try a new kernel on my board. Eventually we'll be moving into omap2plus_defconfig that pretty much builds everything as modules and requires use of an initramfs.. But until we're there yes I agree this makes life easier for booting beagle and panda devices with the omap2plus_defconfig. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote: On 27 June 2012 13:43, Tomi Valkeinen tomi.valkei...@ti.com wrote: I don't like it at all that omapdss disables and enables the panels in omapdss's suspend/resume hooks. But I'm not sure how this should work... Should panel drivers each have their own suspend/resume hooks, and handle it themselves? Or should the call to suspend/resume come from upper layers, like omapfb or omapdrm. I made a prototype patch a few weeks ago to move the suspend to omapfb, and it feels better than the current one, but I'm still not sure... IIUC, I have similar opinion. Each panel having its own suspend/resume sounds like inter-dependency trouble. What do you mean with that? If we just consider omapdss and the panel drivers, I see no dependency trouble. Panels are independent of each other, and omapdss is supposed to handle any locking refcounting related to multiple panels already, as from omapdss's point of view panel suspend is the same as panel disable. And if we take omapfb/omapdrm into equation, well, in any case it couldn't be any worse than the current one where suspend is handled by omapdss. I too would prefer suspend/resume propagating from omap-fb/drm, which imho fits better with the notion of a linux device(omapdss is only backend). Though I don't have strong feelings about how core then take various panels up/down optimally. One one hand, I see the combination of omapdss (or the output side of omapdss) and a panel as a whole entity. I mean, if you just load omapdss and a panel driver, but no omapfb/omapdrm, you already have a working panel. You don't _need_ omapfb/omapdrm there. And in that sense it'd make sense if the panels did handle their own suspend/resume. But then, in real life it may be just simpler if omapfb/omapdrm handles the suspend. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 1/1] ARM: only call smp_send_stop() on SMP
Err,
There was a patch been sent in response that did exactly as you asked.
http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/00433.html
Regards
-- Pantelis
On Jun 24, 2012, at 11:59 AM, Russell King - ARM Linux wrote:
See this thread:
http://lists.arm.linux.org.uk/lurker/thread/20120523.200015.2fdfd505.en.html
There are times when I wonder why I bother replying to email on mailing
lists. No patch ever came from my responses on this subject. Not going
to repeat it again. Fed up.
On Sun, Jun 24, 2012 at 06:21:07AM +0200, Javier Martinez Canillas wrote:
On reboot or poweroff (machine_shutdown()) a call to smp_send_stop() is
made (to stop the others CPU's) when CONFIG_SMP=y.
arch/arm/kernel/process.c:
void machine_shutdown(void)
{
#ifdef CONFIG_SMP
smp_send_stop();
#endif
}
smp_send_stop() calls the function pointer smp_cross_call(), which is set
on the smp_init_cpus() function for OMAP processors.
arch/arm/mach-omap2/omap-smp.c:
void __init smp_init_cpus(void)
{
...
set_smp_cross_call(gic_raise_softirq);
...
}
But the ARM setup_arch() function only calls smp_init_cpus()
if CONFIG_SMP=y is_smp().
arm/kernel/setup.c:
void __init setup_arch(char **cmdline_p)
{
...
#ifdef CONFIG_SMP
if (is_smp())
smp_init_cpus();
#endif
...
}
Newer OMAP CPU's are SMP machines so omap2plus_defconfig sets
CONFIG_SMP=y. Unfortunately on an OMAP UP machine is_smp()
returns false and smp_init_cpus() is never called and the
smp_cross_call() function remains NULL.
If the machine is rebooted or powered off, smp_send_stop() will
be called (since CONFIG_SMP=y) leading to the following error:
[ 42.815551] Restarting system.
[ 42.819030] Unable to handle kernel NULL pointer dereference at virtual
address
[ 42.827667] pgd = d7a74000
[ 42.830566] [] *pgd=96ce7831, *pte=, *ppte=
[ 42.837249] Internal error: Oops: 8007 [#1] SMP ARM
[ 42.842773] Modules linked in:
[ 42.846008] CPU: 0Not tainted
(3.5.0-rc3-next-20120622-2-g62e87ba-dirty #44)
[ 42.854278] PC is at 0x0
[ 42.856994] LR is at smp_send_stop+0x4c/0xe4
[ 42.861511] pc : []lr : [c00183a4]psr: 6013
[ 42.861511] sp : d6c85e70 ip : fp :
[ 42.873626] r10: r9 : d6c84000 r8 : 0002
[ 42.879150] r7 : c07235a0 r6 : c06dd2d0 r5 : 000f4241 r4 : d6c85e74
[ 42.886047] r3 : r2 : r1 : 0006 r0 : d6c85e74
[ 42.892944] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment
user
[ 42.900482] Control: 10c5387d Table: 97a74019 DAC: 0015
[ 42.906555] Process reboot (pid: 1166, stack limit = 0xd6c842f8)
[ 42.912902] Stack: (0xd6c85e70 to 0xd6c86000)
[ 42.917510] 5e60: c07235a0
d6c84000
[ 42.926177] 5e80: 01234567 c00143d0 4321fedc c00511bc d6c85ebc 0168
0460
[ 42.934814] 5ea0: c1017950 a013 c1017900 d8014390 d7ec3858 c0498e48
c1017950
[ 42.943481] 5ec0: d6ddde10 d6c85f78 0003 d6ddde10 d6c84000
[ 42.952117] 5ee0: 0002 c0088c88 0002
c00f4b90
[ 42.960784] 5f00: d6c85ebc d8014390 d7e311c8 6013 0103
0002 d6c84000
[ 42.969421] 5f20: c00f3274 d6e00a00 0001 6013 d6c84000
c00895d4
[ 42.978057] 5f40: 0002 d8007c80 d781f000 c00f6150 d8010cc0 c00f3274
d781f000 d6c84000
[ 42.986694] 5f60: c0013020 d6e00a00 0001 2010 0001257c ef00
c00895d4
[ 42.995361] 5f80: 0002 0001 0003 0001 0003
0058
[ 43.003997] 5fa0: c00130c8 c0012f00 0001 0003 fee1dead 28121969
01234567 0002
[ 43.012634] 5fc0: 0001 0003 0058 00012584 0001257c
0001
[ 43.021270] 5fe0: 000124bc bec5cc6c 8f9c 4a2f7c40 2010 fee1dead
[ 43.029968] [c00183a4] (smp_send_stop+0x4c/0xe4) from [c00143d0]
(machine_restart+0xc/0x4c)
[ 43.039154] [c00143d0] (machine_restart+0xc/0x4c) from [c00511bc]
(sys_reboot+0x144/0x1f0)
[ 43.048278] [c00511bc] (sys_reboot+0x144/0x1f0) from [c0012f00]
(ret_fast_syscall+0x0/0x3c)
[ 43.057464] Code: bad PC value
[ 43.060760] ---[ end trace c3988d1dd0b8f0fb ]---
An is_smp() check is also necessary besides shilding the smp_send_stop()
call around CONFIG_SMP.
Signed-off-by: Javier Martinez Canillas jav...@dowhile0.org
---
arch/arm/kernel/process.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 864580a..a9043b8 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -38,6 +38,7 @@
#include asm/thread_notify.h
#include asm/stacktrace.h
#include asm/mach/time.h
+#include asm/smp_plat.h
#ifdef
[GIT PULL] omap fixes for v3.5-rc4
The following changes since commit 6b16351acbd415e66ba16bf7d473ece1574cf0bc: Linux 3.5-rc4 (2012-06-24 12:53:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-fixes-for-v3.5-rc4 for you to fetch changes up to e90b833ee1aae64b6fca2455001323ffe29e1698: ARM: OMAP4470: Fix OMAP4470 boot failure (2012-06-27 08:09:59 -0700) Here's one more regression fix that I missed earlier, and a trivial fix to get omap4470 booting. Jon Hunter (1): ARM: OMAP4470: Fix OMAP4470 boot failure Kevin Hilman (1): ARM: OMAP2+: nand: fix build error when CONFIG_MTD_ONENAND_OMAP2=n arch/arm/mach-omap2/board-flash.c|5 - arch/arm/mach-omap2/clock44xx_data.c |5 - 2 files changed, 4 insertions(+), 6 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] OMAPDSS: Check if RPM enabled before trying to change state
On 28 June 2012 12:11, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote: On 27 June 2012 13:43, Tomi Valkeinen tomi.valkei...@ti.com wrote: I don't like it at all that omapdss disables and enables the panels in omapdss's suspend/resume hooks. But I'm not sure how this should work... Should panel drivers each have their own suspend/resume hooks, and handle it themselves? Or should the call to suspend/resume come from upper layers, like omapfb or omapdrm. I made a prototype patch a few weeks ago to move the suspend to omapfb, and it feels better than the current one, but I'm still not sure... IIUC, I have similar opinion. Each panel having its own suspend/resume sounds like inter-dependency trouble. What do you mean with that? If we just consider omapdss and the panel drivers, I see no dependency trouble. Panels are independent of each other, and omapdss is supposed to handle any locking refcounting related to multiple panels already, as from omapdss's point of view panel suspend is the same as panel disable. And if we take omapfb/omapdrm into equation, well, in any case it couldn't be any worse than the current one where suspend is handled by omapdss. I just anticipate it not trivial keeping omap_dss_device.state in sync with omap_dss_driver.suspend/resume when the latter is made system suspend/resume and former still affected by hdmi_panel_disable/enable. Perhaps .disable and .suspend would need merging? But as I said, it 'sounds' like. It all may be straight forward - you would know better. I too would prefer suspend/resume propagating from omap-fb/drm, which imho fits better with the notion of a linux device(omapdss is only backend). Though I don't have strong feelings about how core then take various panels up/down optimally. One one hand, I see the combination of omapdss (or the output side of omapdss) and a panel as a whole entity. I mean, if you just load omapdss and a panel driver, but no omapfb/omapdrm, you already have a working panel. You don't _need_ omapfb/omapdrm there. And in that sense it'd make sense if the panels did handle their own suspend/resume. Well, I would think if omapdss+panels (backend) serve none other omapfb/drm, they should simply lie dormant hogging no resources if the omapfb/drm driver isn't loaded (if that isn't already the case). Also one usually has tighter control over a private subsystem by having only one point of intervention by system as compared to two or more. But then, in real life it may be just simpler if omapfb/omapdrm handles the suspend. Yeah, being a simpler option is always there. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On Wed, 2012-06-27 at 19:35 +0530, jaswinder.si...@linaro.org wrote:
From: Jassi Brar jaswinder.si...@linaro.org
We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C.
This could also help some cheapo displays that provide EDID reliably only
immediately after asserting HPD and not later.
Even with good displays, there is something in OMAPDSS that apparantly
messes up DDC occasionally while EDID is being read, giving the
operation stopped when reading edid error.
Btw, this is in nitpicking area, but what editor do you use? I find it
difficult to read text that is not formatted properly =). At least vim
formats text nicely with its formating commands.
Signed-off-by: Jassi Brar jaswinder.si...@linaro.org
---
drivers/video/omap2/dss/hdmi.c|1 +
drivers/video/omap2/dss/ti_hdmi.h |2 ++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 15 +--
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 0738090..9853621 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -758,6 +758,7 @@ static int __init omapdss_hdmihw_probe(struct
platform_device *pdev)
hdmi.ip_data.core_av_offset = HDMI_CORE_AV;
hdmi.ip_data.pll_offset = HDMI_PLLCTRL;
hdmi.ip_data.phy_offset = HDMI_PHY;
+ hdmi.ip_data.edid_len = 0; /* Invalidate EDID Cache */
mutex_init(hdmi.ip_data.lock);
hdmi_panel_init();
diff --git a/drivers/video/omap2/dss/ti_hdmi.h
b/drivers/video/omap2/dss/ti_hdmi.h
index cc292b8..4735860 100644
--- a/drivers/video/omap2/dss/ti_hdmi.h
+++ b/drivers/video/omap2/dss/ti_hdmi.h
@@ -178,6 +178,8 @@ struct hdmi_ip_data {
/* ti_hdmi_4xxx_ip private data. These should be in a separate struct */
int hpd_gpio;
struct mutex lock;
+ u8 edid_cached[256];
+ unsigned edid_len;
};
int ti_hdmi_4xxx_phy_enable(struct hdmi_ip_data *ip_data);
void ti_hdmi_4xxx_phy_disable(struct hdmi_ip_data *ip_data);
diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 04acca9..b5c3dc4 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
There's a problem with this patch, which leaves a wrong EDID in the
cache: if you first have the cable connected and hdmi is enabled, you
then turn off the HDMI display device via sysfs, we do not go to
hdmi_check_hpd_state at all. The next time hdmi is enabled, we only get
the plug-in event, and thus EDID cache is never invalidated.
Perhaps the EDID cache should be invalidated always in
hdmi_check_hpd_state. In that case I think there's a chance
(theoretical, perhaps), that we get two hpd interrupts, and for both the
hpd gpio reads 1. I'm not quite sure what that would imply (perhaps we
just missed the hpd gpio = 0 case), but even in that case invalidating
the cache sounds ok.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH] OMAPDSS: Check if RPM enabled before trying to change state
On Thu, 2012-06-28 at 13:16 +0530, Jassi Brar wrote: On 28 June 2012 12:11, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-06-27 at 20:23 +0530, Jassi Brar wrote: On 27 June 2012 13:43, Tomi Valkeinen tomi.valkei...@ti.com wrote: I don't like it at all that omapdss disables and enables the panels in omapdss's suspend/resume hooks. But I'm not sure how this should work... Should panel drivers each have their own suspend/resume hooks, and handle it themselves? Or should the call to suspend/resume come from upper layers, like omapfb or omapdrm. I made a prototype patch a few weeks ago to move the suspend to omapfb, and it feels better than the current one, but I'm still not sure... IIUC, I have similar opinion. Each panel having its own suspend/resume sounds like inter-dependency trouble. What do you mean with that? If we just consider omapdss and the panel drivers, I see no dependency trouble. Panels are independent of each other, and omapdss is supposed to handle any locking refcounting related to multiple panels already, as from omapdss's point of view panel suspend is the same as panel disable. And if we take omapfb/omapdrm into equation, well, in any case it couldn't be any worse than the current one where suspend is handled by omapdss. I just anticipate it not trivial keeping omap_dss_device.state in sync with omap_dss_driver.suspend/resume when the latter is made system suspend/resume and former still affected by hdmi_panel_disable/enable. This state variable is something I'd like to get rid of. While I think it could work fine if we added some locking to omap_dss_device, I'd actually like to get rid of omap_dss_device also. (totally another issue, let's not go there). But anyway, the state variable should only be written by the panel driver, so I don't see a big problem there. The panel's disable/enable/suspend/resume touch the state, but the panel driver should protect that with a mutex. Perhaps .disable and .suspend would need merging? Yes, I already have a patch that removes suspend/resume from omap_dss_device, as they are identical to disable/enable. I haven't merged it yet, as there's some funny code in omapdrm that breaks after the change, and I haven't had time to look at it. But as I said, it 'sounds' like. It all may be straight forward - you would know better. I too would prefer suspend/resume propagating from omap-fb/drm, which imho fits better with the notion of a linux device(omapdss is only backend). Though I don't have strong feelings about how core then take various panels up/down optimally. One one hand, I see the combination of omapdss (or the output side of omapdss) and a panel as a whole entity. I mean, if you just load omapdss and a panel driver, but no omapfb/omapdrm, you already have a working panel. You don't _need_ omapfb/omapdrm there. And in that sense it'd make sense if the panels did handle their own suspend/resume. Well, I would think if omapdss+panels (backend) serve none other omapfb/drm, they should simply lie dormant hogging no resources if the omapfb/drm driver isn't loaded (if that isn't already the case). That should be the case. I need to look more carefully what fb/drm already do. If they already have good suspend mechanisms and expect to be the ones handling system suspend, then I guess the choice is quite clear. Tomi signature.asc Description: This is a digitally signed message part
[GIT PULL] ARM: OMAP AM35xx: some fixes for 3.6 (fwd)
Got the l-o list address wrong, sigh... - Paul -- Forwarded message -- Date: Thu, 28 Jun 2012 02:19:47 -0600 (MDT) From: Paul Walmsley p...@pwsan.com To: t...@atomide.com Cc: linux-o...@vger.kernel.com, linux-arm-ker...@lists.infradead.org Subject: [GIT PULL] ARM: OMAP AM35xx: some fixes for 3.6 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 6b16351acbd415e66ba16bf7d473ece1574cf0bc: Linux 3.5-rc4 (2012-06-24 12:53:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git for you to fetch changes up to a77e1c4d09c88f98ac2e653382d2c1861dbb736f: Merge branches 'am35xx_hwmod_data_fixes_a_3.6', 'am35xx_emac_mdio_devel_3.6' and 'am35xx_prcm_data_devel_3.6' into am35xx_devel_3.6 (2012-06-28 00:13:19 -0600) - Some OMAP AM35xx fixes. The powerdomain and clockdomain data for the AM35xx are finally fixed. The AM35xx EMAC/MDIO Ethernet controller integration code has been converted to use the OMAP device and hwmod framework. Also the UART4 and HSOTGUSB warnings have been fixed. - Test logs are at: http://www.pwsan.com/omap/testlogs/am35xx_devel_3.6/20120628014213/ On 3530ES3 Beagle, wakeup from dynamic retention idle is broken; can be worked around by reverting commit 91930652a23de0873a157aa1d9962cb878d64451 (OMAP2+: UART: Add mechanism to probe uart pins and configure rx wakeup). On 3530ES3 Beagle and 37xx EVM, CORE powerdomain won't enter retention. On 37xx EVM, CORE powerdomain won't enter off. On 4430ES2 Panda, the serial port prints garbage at the end of long transmissions when dynamic idle is enabled. All of these problems are present with stock v3.5-rc4; none of them were added by this series. object size (delta in bytes from test_v3.5-rc4 (6b16351acbd415e66ba16bf7d473ece1574cf0bc)): textdata bss total kernel 0 0 0 0 5912osk_testconfig/vmlinux +124 +2464 0 +2588 am33xx_testconfig/vmlinux 0 0 0 0 n800_b_testconfig/vmlinux 0 0 0 0 n800_multi_omap2xxx/vmlinux 0 0 0 0 n800_testconfig/vmlinux 0 0 0 0 omap1510_defconfig/vmlinux 0 0 0 0 omap1_defconfig/vmlinux 0 0 0 0 omap2_4_testconfig/vmlinux +104 +2520 0 +2624 omap2plus_defconfig/vmlinux +104 +2200 0 +2304 omap2plus_no_pm/vmlinux +104 +2456 0 +2560 omap3_4_testconfig/vmlinux +104 +2488 0 +2592 omap3_testconfig/vmlinux 0 0 0 0 omap4_testconfig/vmlinux Mark A. Greer (3): ARM: OMAP AM35x: EMAC/MDIO integration: Add Davinci EMAC/MDIO hwmod support ARM: OMAP AM35x: clockdomain data: Fix clockdomain dependencies arm: omap3: am35x: Set proper powerdomain states Paul Walmsley (4): ARM: OMAP AM35xx: clock and hwmod data: fix AM35xx HSOTGUSB hwmod ARM: OMAP AM35xx: clock and hwmod data: fix UART4 data ARM: OMAP: AM35xx: fix UART4 softreset Merge branches 'am35xx_hwmod_data_fixes_a_3.6', 'am35xx_emac_mdio_devel_3.6' and 'am35xx_prcm_data_devel_3.6' into am35xx_devel_3.6 arch/arm/mach-omap2/am35xx-emac.c | 90 +++ arch/arm/mach-omap2/clock3xxx_data.c| 28 +++-- arch/arm/mach-omap2/clockdomains3xxx_data.c | 157 --- arch/arm/mach-omap2/cm-regbits-34xx.h |4 +- arch/arm/mach-omap2/include/mach/am35xx.h |2 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 143 ++-- arch/arm/mach-omap2/powerdomains3xxx_data.c | 139 ++-- arch/arm/mach-omap2/prcm-common.h |4 +- 8 files changed, 471 insertions(+), 96 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJP7BM8AAoJEMePsQ0LvSpLwtoQAKjqee7aQanU7/8mbKqekQ9q HQpwUoRU0tu8dfUQmXwA+OuHQSGTL7wly/McmBSvDQLusT6o3cDqUDi0b3PP64zJ GIdBXb+0NbQyx29CkuHRBcOGAPS5m2StAwwuj2gugGt1rquMk9JHlcEZAWgjB3Yk jLduAMf16ECF+CjZifq6lAq+Ha+TXBQg8hJMf5bgfbGFQ3ax4SEi8QvLtB9OZ4NU nxjomr/zqwk8mlofeB1YFMPKyIFrodFWEJhoTy7HNmKlToselnSnUFapL6JuwDkC JbU0XvYEaesZJcbGLCB0OQDgNnKKwkCLzjFaDoZViFNJ2U4JljupkHN71HZ4y+W6 SzPZDETutIxa3190NuN6LTYq8Oe+jwg+pbogKqgeODz89CKK8DbLQ6AIarkS3SX0 w+1/TcVfwQtFRg/tZANC+nT4LP98po0SU+yZA6lMiFpEjw1BgKhosJPog0Dozd5V n/lmgGhb8KTT8KWv+iDva2PBuRN82NKISZHjc7oCPilzRBAcQm54jsEsA2KwwFaA PQC2gB+zOWRLAyqS2xneAIlnH0cOgmGFXS0RmsSQ2AvaYrK+PQHbPgQ7Sw+vUJx1 finzAVGI5qOGZPt+L+OrSblPRdUAlLkfcTSJxYtvWlmzl3FGikGIbn1D+J3UlTbX h4exg8Cju+199gySOwcL =6PAM -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
OMAP4430ES2 UART garbage on v3.5-rc4
Hi, On 4430ES2 Panda, the serial port prints garbage at the end of long transmissions from the board when dynamic idle is enabled. Here's an example (search for Minicom2.6.1): http://www.pwsan.com/omap/testlogs/am35xx_devel_3.6/20120628014213/pm/4430es2panda_log.txt My recollection is that this used to happen on some earlier kernels after the OMAP serial Ragnarok a few months ago, but it was masked by some other issue up until v3.5-rc4.. Who is looking after the OMAP UART driver these days? - 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
New compiler warnings with v3.5-rc
Hi Tero, there are some new compiler warnings added in the v3.5-rc kernels: arch/arm/mach-omap2/twl-common.c:51:12: warning: 'twl_set_voltage' defined but not used arch/arm/mach-omap2/twl-common.c:57:12: warning: 'twl_get_voltage' defined but not used They only seem to appear on my N800 builds: http://www.pwsan.com/omap/testlogs/am35xx_devel_3.6/20120628014213/build/build_20120628011813_log.txt but it looks like I somehow am not doing a 2430-specific build yet, so they may be 24xx-common. Anyway they were probably added by: commit 49c008ecce1f9a549c12e8957668d60008ab0d79 Author: Tero Kristo t-kri...@ti.com Date: Mon Feb 20 12:26:08 2012 +0200 arm: omap3: twl: add external controllers for core voltage regulators Maybe you can put together a quick patch to fix these? - 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: New compiler warnings with v3.5-rc
On Thu, 2012-06-28 at 02:47 -0600, Paul Walmsley wrote: Hi Tero, there are some new compiler warnings added in the v3.5-rc kernels: arch/arm/mach-omap2/twl-common.c:51:12: warning: 'twl_set_voltage' defined but not used arch/arm/mach-omap2/twl-common.c:57:12: warning: 'twl_get_voltage' defined but not used They only seem to appear on my N800 builds: http://www.pwsan.com/omap/testlogs/am35xx_devel_3.6/20120628014213/build/build_20120628011813_log.txt but it looks like I somehow am not doing a 2430-specific build yet, so they may be 24xx-common. Anyway they were probably added by: commit 49c008ecce1f9a549c12e8957668d60008ab0d79 Author: Tero Kristo t-kri...@ti.com Date: Mon Feb 20 12:26:08 2012 +0200 arm: omap3: twl: add external controllers for core voltage regulators Maybe you can put together a quick patch to fix these? Yea, I can do that. Can you provide your .config as reference? -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/2] OMAP:IOMMU:flush L1 and L2 caches
From a5dc6e2ebee40b4f6cf51c1ec3c67476ffb8efc3 Mon Sep 17 00:00:00 2001 From: Ramesh Gupta G grgu...@ti.com Date: Thu, 28 Jun 2012 11:53:54 +0530 Subject: [PATCH v3 0/2] OMAP:IOMMU:flush L1 and L2 caches This patch series is the next version to - add a new cache maintenance api to support non-coherent iommu drivers. - flush both L1 and L2 caches from OMAP iommu whenever the page table memory is updated. Changes since the previous patch set - Renamed the new api to reflect the purpose. - Fixed the kernel compilation issues by adding the new api support for all the ARM versions. - Validated the changes on the Pandaboard. - Compile tested the kernel for all other ARM configurations. The implementation of the new api is based on the approach[1] discussed. [1]http://marc.info/?l=linux-kernelm=131316512713815w=2 Signed-off-by: Ramesh Gupta G grgu...@ti.com Ramesh Gupta G (2): ARM: new cache maintenance api for iommu OMAP:IOMMU:flush L1 and L2 caches arch/arm/include/asm/cacheflush.h | 26 ++ arch/arm/include/asm/glue-cache.h |1 + arch/arm/mm/cache-fa.S| 15 +++ arch/arm/mm/cache-v3.S| 14 +- arch/arm/mm/cache-v4.S| 15 +++ arch/arm/mm/cache-v4wb.S | 21 + arch/arm/mm/cache-v4wt.S | 17 + arch/arm/mm/cache-v6.S| 20 arch/arm/mm/cache-v7.S| 21 + arch/arm/mm/proc-arm1020.S| 22 ++ arch/arm/mm/proc-arm1020e.S | 20 arch/arm/mm/proc-arm1022.S| 20 arch/arm/mm/proc-arm1026.S| 20 arch/arm/mm/proc-arm920.S | 17 + arch/arm/mm/proc-arm922.S | 17 + arch/arm/mm/proc-arm925.S | 22 ++ arch/arm/mm/proc-arm926.S | 22 ++ arch/arm/mm/proc-arm940.S | 26 ++ arch/arm/mm/proc-arm946.S | 24 arch/arm/mm/proc-feroceon.S | 30 ++ arch/arm/mm/proc-macros.S |1 + arch/arm/mm/proc-mohawk.S | 18 ++ arch/arm/mm/proc-xsc3.S | 17 + arch/arm/mm/proc-xscale.S | 19 +++ drivers/iommu/omap-iommu.c| 26 +- 25 files changed, 453 insertions(+), 18 deletions(-) -- regards Ramesh Gupta G -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote: The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Sorry for the delayed response, could reach workplace a short while ago only Could the diff [1] be tried and check whether it resolves the issue, Regards Afzal [1] diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/2] ARM: new cache maintenance api for iommu
From 95b900d845537ab755bfcef50e956ee03e89a2c5 Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Wed, 27 Jun 2012 16:50:32 +0530
Subject: [PATCH v3 1/2] ARM: new cache maintenance api for iommu
Non-coherent IOMMU drivers need to make sure
that the data held in the caches is available
for the slave processor MMU hardware whenever
there is an update to the page table memory of
the slave processor.
The page table memory is always updated from
the main processor and read from the slave
processor MMU.
A new cache maintenance api flush_iommu_mem is
added to handle this.The api clean and invalidate
the specified virtual address range (the page table
memory range that need to be flushed).The
implementation is based on the dma cache apis.
Thanks to RMK's suggestions on creating a
dedicated API for this purpose.
ref:http://marc.info/?l=linux-kernelm=131316512713815w=2
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
arch/arm/include/asm/cacheflush.h | 26 ++
arch/arm/include/asm/glue-cache.h |1 +
arch/arm/mm/cache-fa.S| 15 +++
arch/arm/mm/cache-v3.S| 14 +-
arch/arm/mm/cache-v4.S| 15 +++
arch/arm/mm/cache-v4wb.S | 21 +
arch/arm/mm/cache-v4wt.S | 17 +
arch/arm/mm/cache-v6.S| 20
arch/arm/mm/cache-v7.S| 21 +
arch/arm/mm/proc-arm1020.S| 22 ++
arch/arm/mm/proc-arm1020e.S | 20
arch/arm/mm/proc-arm1022.S| 20
arch/arm/mm/proc-arm1026.S| 20
arch/arm/mm/proc-arm920.S | 17 +
arch/arm/mm/proc-arm922.S | 17 +
arch/arm/mm/proc-arm925.S | 22 ++
arch/arm/mm/proc-arm926.S | 22 ++
arch/arm/mm/proc-arm940.S | 25 +
arch/arm/mm/proc-arm946.S | 24
arch/arm/mm/proc-feroceon.S | 30 ++
arch/arm/mm/proc-macros.S |1 +
arch/arm/mm/proc-mohawk.S | 18 ++
arch/arm/mm/proc-xsc3.S | 17 +
arch/arm/mm/proc-xscale.S | 19 +++
24 files changed, 443 insertions(+), 1 deletions(-)
diff --git a/arch/arm/include/asm/cacheflush.h
b/arch/arm/include/asm/cacheflush.h
index d5d8d5c..64700e0 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -84,6 +84,16 @@
* - kaddr - page address
* - size - region size
*
+ * flush_iommu_mem(start, end)
+ *
+ * Clean and invalidate the specified virtual address range.
+ * This is to support the non coherent iommu drivers.
+ * The iommu driver need to call this api with the page
+ * table memory address range to ensure the data held in
+ * the cache is visible to the slave processor MMU.
+ * - start - virtual start address
+ * - end- virtual end address
+ *
* DMA Cache Coherency
* ===
*
@@ -108,6 +118,7 @@ struct cpu_cache_fns {
void (*dma_unmap_area)(const void *, size_t, int);
void (*dma_flush_range)(const void *, const void *);
+ void (*flush_iommu_mem)(const void *, const void *);
};
/*
@@ -135,6 +146,14 @@ extern struct cpu_cache_fns cpu_cache;
#define dmac_unmap_areacpu_cache.dma_unmap_area
#define dmac_flush_range cpu_cache.dma_flush_range
+/* This API is to support non-coherent IOMMUs. The purpose of
+ * this API is to ensure that the data held in the cache is visible
+ * to the MMU of the slave processor. This is called from
+ * the IOMMU driver whenever there is an update in the page tables
+ * for the slave processor.
+ */
+#define flush_iommu_memcpu_cache.flush_iommu_mem
+
#else
extern void __cpuc_flush_icache_all(void);
@@ -155,6 +174,13 @@ extern void dmac_map_area(const void *, size_t, int);
extern void dmac_unmap_area(const void *, size_t, int);
extern void dmac_flush_range(const void *, const void *);
+/* This API is to support non-coherent IOMMUs. The purpose of
+ * this API is to ensure that the data held in the cache is visible
+ * to the MMU of the slave processor. This is called from
+ * the IOMMU driver whenever there is an update in the page tables
+ * for the slave processor.
+ */
+extern void flush_iommu_mem(const void *, const void *);
#endif
/*
diff --git a/arch/arm/include/asm/glue-cache.h
b/arch/arm/include/asm/glue-cache.h
index 7e30874..2c2213b 100644
--- a/arch/arm/include/asm/glue-cache.h
+++ b/arch/arm/include/asm/glue-cache.h
@@ -141,6 +141,7 @@
#define dmac_map_area
[PATCH v3 2/2] OMAP:IOMMU:flush L1 and L2 caches
From ad8097177ca6c43d98d0641ea881936fe328b4dc Mon Sep 17 00:00:00 2001
From: Ramesh Gupta G grgu...@ti.com
Date: Fri, 15 Jun 2012 16:46:46 +0530
Subject: [PATCH v3 2/2] OMAP:IOMMU:flush L1 and L2 caches
OMAP IOMMU need to make sure that data in the L1 and L2
caches is visible to the MMU hardware whenever the
page tables are updated. The current code only takes
care of L1 cache using assembly code. Added code to
handle this using a new L1 cache maintenance function
and the outer cache function.
Signed-off-by: Ramesh Gupta G grgu...@ti.com
---
drivers/iommu/omap-iommu.c | 26 +-
1 files changed, 9 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 6899dcd..f909019 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -469,22 +469,14 @@ EXPORT_SYMBOL_GPL(omap_foreach_iommu_device);
*/
static void flush_iopgd_range(u32 *first, u32 *last)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pgd
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ flush_iommu_mem(first, last);
+ outer_flush_range(virt_to_phys(first), virt_to_phys(last));
}
static void flush_iopte_range(u32 *first, u32 *last)
{
- /* FIXME: L2 cache should be taken care of if it exists */
- do {
- asm(mcrp15, 0, %0, c7, c10, 1 @ flush_pte
- : : r (first));
- first += L1_CACHE_BYTES / sizeof(*first);
- } while (first = last);
+ flush_iommu_mem(first, last);
+ outer_flush_range(virt_to_phys(first), virt_to_phys(last));
}
static void iopte_free(u32 *iopte)
@@ -513,7 +505,7 @@ static u32 *iopte_alloc(struct omap_iommu *obj,
u32 *iopgd, u32 da)
return ERR_PTR(-ENOMEM);
*iopgd = virt_to_phys(iopte) | IOPGD_TABLE;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
dev_vdbg(obj-dev, %s: a new pte:%p\n, __func__, iopte);
} else {
@@ -542,7 +534,7 @@ static int iopgd_alloc_section(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
}
*iopgd = (pa IOSECTION_MASK) | prot | IOPGD_SECTION;
- flush_iopgd_range(iopgd, iopgd);
+ flush_iopgd_range(iopgd, iopgd + 1);
return 0;
}
@@ -559,7 +551,7 @@ static int iopgd_alloc_super(struct omap_iommu
*obj, u32 da, u32 pa, u32 prot)
for (i = 0; i 16; i++)
*(iopgd + i) = (pa IOSUPER_MASK) | prot | IOPGD_SUPER;
- flush_iopgd_range(iopgd, iopgd + 15);
+ flush_iopgd_range(iopgd, iopgd + 16);
return 0;
}
@@ -700,7 +692,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
}
bytes *= nent;
memset(iopte, 0, nent * sizeof(*iopte));
- flush_iopte_range(iopte, iopte + (nent - 1) * sizeof(*iopte));
+ flush_iopte_range(iopte, iopte + nent * sizeof(*iopte));
/*
* do table walk to check if this table is necessary or not
@@ -722,7 +714,7 @@ static size_t iopgtable_clear_entry_core(struct
omap_iommu *obj, u32 da)
bytes *= nent;
}
memset(iopgd, 0, nent * sizeof(*iopgd));
- flush_iopgd_range(iopgd, iopgd + (nent - 1) * sizeof(*iopgd));
+ flush_iopgd_range(iopgd, iopgd + nent * sizeof(*iopgd));
out:
return bytes;
}
--
1.7.0.4
--
regards
Ramesh Gupta G
--
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 2/7] mfd: omap: control: core system control driver
Hi.
On 06/28/2012 08:50 AM, Eduardo Valentin wrote:
Hello,
On Wed, Jun 27, 2012 at 10:04:54PM +0400, Konstantin Baydarov wrote:
This patch introduces a MFD core device driver for OMAP system control
module.
The control module allows software control of various static modes supported
by the device.
It is composed of two control submodules: general control module and device
(padconfiguration) control module.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts
file.
- omap-control-core: Control module is a built-in driver - added control
module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4.
Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module
IOMEM window, this allows access of SCM registers very early, for example
from omap_type()
- omap-control-core: Removed device pointer from omap-control-core API
arguments, becuase there can be only one instance control
module device.
- omap-control-core: removed omap_control_get, omap_control_readl,
omap_control_writel
- omap-control-core: added omap_control_status_read that is used early in
omap_type
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../devicetree/bindings/mfd/omap_control.txt | 44 +++
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/plat-omap/Kconfig |4 +
drivers/mfd/Kconfig|9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 131
include/linux/mfd/omap_control.h | 52
7 files changed, 242 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt
create mode 100644 drivers/mfd/omap-control-core.c
create mode 100644 include/linux/mfd/omap_control.h
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..46d5e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes
supported by
+the device. The control module controls the settings of various device
modules
+through register configuration and internal signals. It also controls the
pad
+configuration, pin functional multiplexing, and the routing of internal
signals
+(such as PRCM signals or DMA requests) to output pins configured for
hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+ - ti,omap3-control for OMAP3 support
+ - ti,omap4-control for OMAP4 support
+ - ti,omap5-control for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+ Should be ctrl_module_core;
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+ The bindings details of individual bandgap device can be found in:
+ Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+ The only required property for this child is:
+- compatible = ti,omap4-control-usb;
+
+Examples:
+
+ctrl_module_core: ctrl_module_core@4a002000 {
+compatible = ti,omap4-control;
+ti,hwmods = ctrl_module_core;
+bandgap {
+compatible = ti,omap4460-bandgap;
You need to update the documentation if change the DT structure.
Ok.
+interrupts = 0 126 4; /* talert */
+ti,tshut-gpio = 86; /* tshut */
+};
+usb {
+compatible = ti,omap4-usb-phy;
+};
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4cf5142..c2ef07c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -52,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+select ARCH_HAS_CONTROL_MODULE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..0f9b575 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+bool
+select MFD_OMAP_CONTROL
+
OK now I got what you meant in patch 0. Fine for me.
choice
prompt OMAP System Type
default ARCH_OMAP2PLUS
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e129c82..d0c5456 100644
[PATCH 0/4] Add LCD3 channel support
Hi everyone! This following patch series enables LCD3 support which consists of two patches. The 1st patch * adds enum mgr_reg_fields to describe various register fields manipulated for LCD support * replaces if-else checks for LCD implementation with simpler interface with the help of data from struct mgr_desc The 2nd Patch * adds LCD3 channel support * updates DISPC registers for LCD3 support The 3rd patch * enables LCD3 manager DSS feature * adds enables clock support for LCD3 * adds IRQs specific to LCD3 manager The 4th patch * enables dispc functions to provide dump functionality for clocks and IRQs specific to LCD3 This patch was based on mainline kernel v3.5rc4. All your comments and suggestions are welcome. Regards, Chandrabhanu Chandrabhanu Mahapatra (4): OMAPDSS: Cleanup implementation of LCD channels OMAPDSS: Add support for LCD3 channel OMAPDSS: Add LCD3 overlay manager and Clock and IRQ support OMAPDSS: Add dump and debug support for LCD3 drivers/video/omap2/dss/dispc.c| 351 ++-- drivers/video/omap2/dss/dispc.h| 28 +++ drivers/video/omap2/dss/dsi.c |6 +- drivers/video/omap2/dss/dss.c | 12 +- drivers/video/omap2/dss/dss.h |6 + drivers/video/omap2/dss/dss_features.h |5 +- drivers/video/omap2/dss/manager.c | 16 +- drivers/video/omap2/dss/overlay.c | 14 +- include/video/omapdss.h|6 + 9 files changed, 268 insertions(+), 176 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
[PATCH 1/4] OMAPDSS: Cleanup implementation of LCD channels
The current implementation of LCD channels and managers consists of a number of
if-else construct which has been replaced by a simpler interface. A constant
structure mgr_desc has been created in Display Controller (DISPC) module. The
mgr_desc contains for each channel its name, irqs and is initialized one time
with all registers and their corresponding fields to be written to enable
various features of Display Subsystem. This structure is later used by various
functions of DISPC which simplifies the further implementation of LCD channels
and its corresponding managers.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 233 +
drivers/video/omap2/dss/dsi.c |6 +-
drivers/video/omap2/dss/dss.h |6 +
drivers/video/omap2/dss/manager.c | 12 +--
4 files changed, 121 insertions(+), 136 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4749ac3..6c16b81 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -57,6 +57,8 @@
#define DISPC_MAX_NR_ISRS 8
+#define DISPC_MGR_FLD_MAX 9
+
struct omap_dispc_isr_data {
omap_dispc_isr_tisr;
void*arg;
@@ -119,6 +121,78 @@ enum omap_color_component {
DISPC_COLOR_COMPONENT_UV= 1 1,
};
+enum mgr_reg_fields {
+ DISPC_MGR_FLD_ENABLE,
+ DISPC_MGR_FLD_STNTFT,
+ DISPC_MGR_FLD_GO,
+ DISPC_MGR_FLD_TFTDATALINES,
+ DISPC_MGR_FLD_STALLMODE,
+ DISPC_MGR_FLD_TCKENABLE,
+ DISPC_MGR_FLD_TCKSELECTION,
+ DISPC_MGR_FLD_CPR,
+ DISPC_MGR_FLD_FIFOHANDCHECK,
+};
+
+static const struct {
+ const char *name;
+ u32 vsync_irq;
+ u32 framedone_irq;
+ u32 sync_lost_irq;
+ struct reg_field reg_desc[DISPC_MGR_FLD_MAX];
+} mgr_desc[] = {
+ [OMAP_DSS_CHANNEL_LCD] = {
+ .name = LCD,
+ .vsync_irq = DISPC_IRQ_VSYNC,
+ .framedone_irq = DISPC_IRQ_FRAMEDONE,
+ .sync_lost_irq = DISPC_IRQ_SYNC_LOST,
+ .reg_desc = {
+ [DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL, 0,
0 },
+ [DISPC_MGR_FLD_STNTFT] = { DISPC_CONTROL, 3,
3 },
+ [DISPC_MGR_FLD_GO] = { DISPC_CONTROL, 5,
5 },
+ [DISPC_MGR_FLD_TFTDATALINES]= { DISPC_CONTROL, 9,
8 },
+ [DISPC_MGR_FLD_STALLMODE] = { DISPC_CONTROL, 11,
11 },
+ [DISPC_MGR_FLD_TCKENABLE] = { DISPC_CONFIG, 10,
10 },
+ [DISPC_MGR_FLD_TCKSELECTION]= { DISPC_CONFIG, 11,
11 },
+ [DISPC_MGR_FLD_CPR] = { DISPC_CONFIG, 15,
15 },
+ [DISPC_MGR_FLD_FIFOHANDCHECK] = { DISPC_CONFIG, 16,
16 },
+ },
+ },
+ [OMAP_DSS_CHANNEL_DIGIT] = {
+ .name = DIGIT,
+ .vsync_irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN,
+ .framedone_irq = DISPC_IRQ_FRAMEDONETV,
+ .sync_lost_irq = DISPC_IRQ_SYNC_LOST_DIGIT,
+ .reg_desc = {
+ [DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL, 1,
1 },
+ [DISPC_MGR_FLD_STNTFT] = { },
+ [DISPC_MGR_FLD_GO] = { DISPC_CONTROL, 6,
6 },
+ [DISPC_MGR_FLD_TFTDATALINES]= { },
+ [DISPC_MGR_FLD_STALLMODE] = { },
+ [DISPC_MGR_FLD_TCKENABLE] = { DISPC_CONFIG, 12,
12 },
+ [DISPC_MGR_FLD_TCKSELECTION]= { DISPC_CONFIG, 13,
13 },
+ [DISPC_MGR_FLD_CPR] = { },
+ [DISPC_MGR_FLD_FIFOHANDCHECK] = { DISPC_CONFIG, 16,
16 },
+ },
+ },
+ [OMAP_DSS_CHANNEL_LCD2] = {
+ .name = LCD2,
+ .vsync_irq = DISPC_IRQ_VSYNC2,
+ .framedone_irq = DISPC_IRQ_FRAMEDONE2,
+ .sync_lost_irq = DISPC_IRQ_SYNC_LOST2,
+ .reg_desc = {
+ [DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL2, 0,
0 },
+ [DISPC_MGR_FLD_STNTFT] = { DISPC_CONTROL2, 3,
3 },
+ [DISPC_MGR_FLD_GO] = { DISPC_CONTROL2, 5,
5 },
+ [DISPC_MGR_FLD_TFTDATALINES]= { DISPC_CONTROL2, 9,
8 },
+ [DISPC_MGR_FLD_STALLMODE] = { DISPC_CONTROL2, 11,
11 },
+ [DISPC_MGR_FLD_TCKENABLE] = { DISPC_CONFIG2, 10,
10 },
+ [DISPC_MGR_FLD_TCKSELECTION]= { DISPC_CONFIG2, 11,
11 },
+ [DISPC_MGR_FLD_CPR] = { DISPC_CONFIG2, 15,
[PATCH 2/4] OMAPDSS: Add support for LCD3 channel
OMAP5 Display Subsystem (DSS) architecture comes with a additional LCD3 channel
with its own dedicated overlay manager. The current patch adds LCD3 channel and
basic register support for LCD3 channel. It adds register addresses for various
Display Controller (DISPC) registers like DISPC_DEFAULT_COLOR, DISPC_TIMING_H,
DISPC_DIVISORo, etc.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.h | 26 ++
include/video/omapdss.h |1 +
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h
index f278080..420c980 100644
--- a/drivers/video/omap2/dss/dispc.h
+++ b/drivers/video/omap2/dss/dispc.h
@@ -118,6 +118,8 @@ static inline u16 DISPC_DEFAULT_COLOR(enum omap_channel
channel)
return 0x0050;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03AC;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0814;
default:
BUG();
return 0;
@@ -133,6 +135,8 @@ static inline u16 DISPC_TRANS_COLOR(enum omap_channel
channel)
return 0x0058;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03B0;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0818;
default:
BUG();
return 0;
@@ -149,6 +153,8 @@ static inline u16 DISPC_TIMING_H(enum omap_channel channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x0400;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0840;
default:
BUG();
return 0;
@@ -165,6 +171,8 @@ static inline u16 DISPC_TIMING_V(enum omap_channel channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x0404;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0844;
default:
BUG();
return 0;
@@ -181,6 +189,8 @@ static inline u16 DISPC_POL_FREQ(enum omap_channel channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x0408;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x083C;
default:
BUG();
return 0;
@@ -197,6 +207,8 @@ static inline u16 DISPC_DIVISORo(enum omap_channel channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x040C;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0838;
default:
BUG();
return 0;
@@ -213,6 +225,8 @@ static inline u16 DISPC_SIZE_MGR(enum omap_channel channel)
return 0x0078;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03CC;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0834;
default:
BUG();
return 0;
@@ -229,6 +243,8 @@ static inline u16 DISPC_DATA_CYCLE1(enum omap_channel
channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03C0;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0828;
default:
BUG();
return 0;
@@ -245,6 +261,8 @@ static inline u16 DISPC_DATA_CYCLE2(enum omap_channel
channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03C4;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x082C;
default:
BUG();
return 0;
@@ -261,6 +279,8 @@ static inline u16 DISPC_DATA_CYCLE3(enum omap_channel
channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03C8;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0830;
default:
BUG();
return 0;
@@ -277,6 +297,8 @@ static inline u16 DISPC_CPR_COEF_R(enum omap_channel
channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03BC;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0824;
default:
BUG();
return 0;
@@ -293,6 +315,8 @@ static inline u16 DISPC_CPR_COEF_G(enum omap_channel
channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03B8;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x0820;
default:
BUG();
return 0;
@@ -309,6 +333,8 @@ static inline u16 DISPC_CPR_COEF_B(enum omap_channel
channel)
return 0;
case OMAP_DSS_CHANNEL_LCD2:
return 0x03B4;
+ case OMAP_DSS_CHANNEL_LCD3:
+ return 0x081C;
default:
BUG();
return 0;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index c8e59b4..cf4f716 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -75,6 +75,7 @@ enum omap_channel {
OMAP_DSS_CHANNEL_LCD= 0,
[PATCH 3/4] OMAPDSS: Add LCD3 overlay manager and Clock and IRQ support
The support feature for LCD3 manager has been added into the DSS features
structure. LCD3 panel has registers as DISPC_CONTROL3 and DISPC_CONFIG3 just
like those in LCD and LCD2 panels. These registers control the Display
Controller (DISPC) module for LCD3 output. The three LCDs support Display Serial
Interface (DSI), Remote Frame Buffer Interface (RFBI) and Parallel CMOS Output
Interface (DPI). These LCDs can be connected through parallel output interface
using DISPC and RFBI or DPI. For serial interface DSS uses DSI.
The LCD3 panel, just like LCD and LCD2 panels, has a clock switch in DSS_CTRL
register which has been enabled. The clock switch chooses between DSS_CLK and
DPLL_DSI1_C_CLK1 as source for LCD3_CLK. New IRQs as DISPC_IRQ_VSYNC3,
DISPC_IRQ_FRAMEDONE3, DISPC_IRQ_ACBIAS_COUNT_STAT3 and DISPC_IRQ_SYNC_LOST3 have
been added specific to the new manager.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c| 48 ++-
drivers/video/omap2/dss/dispc.h|2 +
drivers/video/omap2/dss/dss.c | 12 +--
drivers/video/omap2/dss/dss_features.h |5 ++-
drivers/video/omap2/dss/manager.c |4 ++
drivers/video/omap2/dss/overlay.c | 14 -
include/video/omapdss.h|5 +++
7 files changed, 80 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 6c16b81..644ff53 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -191,6 +191,23 @@ static const struct {
[DISPC_MGR_FLD_FIFOHANDCHECK] = { DISPC_CONFIG2, 16,
16 },
},
},
+ [OMAP_DSS_CHANNEL_LCD3] = {
+ .name = LCD3,
+ .vsync_irq = DISPC_IRQ_VSYNC3,
+ .framedone_irq = DISPC_IRQ_FRAMEDONE3,
+ .sync_lost_irq = DISPC_IRQ_SYNC_LOST3,
+ .reg_desc = {
+ [DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL3, 0,
0 },
+ [DISPC_MGR_FLD_STNTFT] = { DISPC_CONTROL3, 3,
3 },
+ [DISPC_MGR_FLD_GO] = { DISPC_CONTROL3, 5,
5 },
+ [DISPC_MGR_FLD_TFTDATALINES]= { DISPC_CONTROL3, 9,
8 },
+ [DISPC_MGR_FLD_STALLMODE] = { DISPC_CONTROL3, 11,
11 },
+ [DISPC_MGR_FLD_TCKENABLE] = { DISPC_CONFIG3, 10,
10 },
+ [DISPC_MGR_FLD_TCKSELECTION]= { DISPC_CONFIG3, 11,
11 },
+ [DISPC_MGR_FLD_CPR] = { DISPC_CONFIG3, 15,
15 },
+ [DISPC_MGR_FLD_FIFOHANDCHECK] = { DISPC_CONFIG3, 16,
16 },
+ },
+ },
};
static void _omap_dispc_set_irqs(void);
@@ -240,6 +257,10 @@ static void dispc_save_context(void)
SR(CONTROL2);
SR(CONFIG2);
}
+ if (dss_has_feature(FEAT_MGR_LCD3)) {
+ SR(CONTROL3);
+ SR(CONFIG3);
+ }
for (i = 0; i dss_feat_get_num_mgrs(); i++) {
SR(DEFAULT_COLOR(i));
@@ -353,6 +374,8 @@ static void dispc_restore_context(void)
RR(GLOBAL_ALPHA);
if (dss_has_feature(FEAT_MGR_LCD2))
RR(CONFIG2);
+ if (dss_has_feature(FEAT_MGR_LCD3))
+ RR(CONFIG3);
for (i = 0; i dss_feat_get_num_mgrs(); i++) {
RR(DEFAULT_COLOR(i));
@@ -438,6 +461,8 @@ static void dispc_restore_context(void)
RR(CONTROL);
if (dss_has_feature(FEAT_MGR_LCD2))
RR(CONTROL2);
+ if (dss_has_feature(FEAT_MGR_LCD3))
+ RR(CONTROL3);
/* clear spurious SYNC_LOST_DIGIT interrupts */
dispc_write_reg(DISPC_IRQSTATUS, DISPC_IRQ_SYNC_LOST_DIGIT);
@@ -477,7 +502,8 @@ void dispc_runtime_put(void)
static inline bool dispc_mgr_is_lcd(enum omap_channel channel)
{
if (channel == OMAP_DSS_CHANNEL_LCD ||
- channel == OMAP_DSS_CHANNEL_LCD2)
+ channel == OMAP_DSS_CHANNEL_LCD2 ||
+ channel == OMAP_DSS_CHANNEL_LCD3)
return true;
else
return false;
@@ -868,6 +894,15 @@ void dispc_ovl_set_channel_out(enum omap_plane plane, enum
omap_channel channel)
chan = 0;
chan2 = 1;
break;
+ case OMAP_DSS_CHANNEL_LCD3:
+ if (dss_has_feature(FEAT_MGR_LCD3)) {
+ chan = 0;
+ chan2 = 2;
+ } else {
+ BUG();
+ return;
+ }
+ break;
default:
BUG();
return;
@@ -903,7 +938,14 @@ static enum omap_channel
[PATCH 4/4] OMAPDSS: Add dump and debug support for LCD3
DISPC functions have been modified to provide clock and register dumps and debug
support for the LCD3 manager.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 70 ++
1 files changed, 40 insertions(+), 30 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 644ff53..29b92ea 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2854,12 +2854,32 @@ unsigned long dispc_core_clk_rate(void)
return fclk / lcd;
}
-void dispc_dump_clocks(struct seq_file *s)
+void dispc_dump_clocks_channel(struct seq_file *s, enum omap_channel channel)
{
int lcd, pcd;
+ enum omap_dss_clk_source lcd_clk_src;
+
+ seq_printf(s, - %s -\n, mgr_desc[channel].name);
+
+ lcd_clk_src = dss_get_lcd_clk_source(channel);
+
+ seq_printf(s, %s clk source = %s (%s)\n, mgr_desc[channel].name,
+ dss_get_generic_clk_source_name(lcd_clk_src),
+ dss_feat_get_clk_source_name(lcd_clk_src));
+
+ dispc_mgr_get_lcd_divisor(channel, lcd, pcd);
+
+ seq_printf(s, lck\t\t%-16lulck div\t%u\n,
+ dispc_mgr_lclk_rate(channel), lcd);
+ seq_printf(s, pck\t\t%-16lupck div\t%u\n,
+ dispc_mgr_pclk_rate(channel), pcd);
+}
+
+void dispc_dump_clocks(struct seq_file *s)
+{
+ int lcd;
u32 l;
enum omap_dss_clk_source dispc_clk_src = dss_get_dispc_clk_source();
- enum omap_dss_clk_source lcd_clk_src;
if (dispc_runtime_get())
return;
@@ -2880,36 +2900,13 @@ void dispc_dump_clocks(struct seq_file *s)
seq_printf(s, lck\t\t%-16lulck div\t%u\n,
(dispc_fclk_rate()/lcd), lcd);
}
- seq_printf(s, - LCD1 -\n);
- lcd_clk_src = dss_get_lcd_clk_source(OMAP_DSS_CHANNEL_LCD);
+ dispc_dump_clocks_channel(s, OMAP_DSS_CHANNEL_LCD);
- seq_printf(s, lcd1_clk source = %s (%s)\n,
- dss_get_generic_clk_source_name(lcd_clk_src),
- dss_feat_get_clk_source_name(lcd_clk_src));
-
- dispc_mgr_get_lcd_divisor(OMAP_DSS_CHANNEL_LCD, lcd, pcd);
-
- seq_printf(s, lck\t\t%-16lulck div\t%u\n,
- dispc_mgr_lclk_rate(OMAP_DSS_CHANNEL_LCD), lcd);
- seq_printf(s, pck\t\t%-16lupck div\t%u\n,
- dispc_mgr_pclk_rate(OMAP_DSS_CHANNEL_LCD), pcd);
- if (dss_has_feature(FEAT_MGR_LCD2)) {
- seq_printf(s, - LCD2 -\n);
-
- lcd_clk_src = dss_get_lcd_clk_source(OMAP_DSS_CHANNEL_LCD2);
-
- seq_printf(s, lcd2_clk source = %s (%s)\n,
- dss_get_generic_clk_source_name(lcd_clk_src),
- dss_feat_get_clk_source_name(lcd_clk_src));
-
- dispc_mgr_get_lcd_divisor(OMAP_DSS_CHANNEL_LCD2, lcd, pcd);
-
- seq_printf(s, lck\t\t%-16lulck div\t%u\n,
- dispc_mgr_lclk_rate(OMAP_DSS_CHANNEL_LCD2),
lcd);
- seq_printf(s, pck\t\t%-16lupck div\t%u\n,
- dispc_mgr_pclk_rate(OMAP_DSS_CHANNEL_LCD2),
pcd);
- }
+ if (dss_has_feature(FEAT_MGR_LCD2))
+ dispc_dump_clocks_channel(s, OMAP_DSS_CHANNEL_LCD2);
+ if (dss_has_feature(FEAT_MGR_LCD3))
+ dispc_dump_clocks_channel(s, OMAP_DSS_CHANNEL_LCD3);
dispc_runtime_put();
}
@@ -2962,6 +2959,12 @@ void dispc_dump_irqs(struct seq_file *s)
PIS(ACBIAS_COUNT_STAT2);
PIS(SYNC_LOST2);
}
+ if (dss_has_feature(FEAT_MGR_LCD3)) {
+ PIS(FRAMEDONE3);
+ PIS(VSYNC3);
+ PIS(ACBIAS_COUNT_STAT3);
+ PIS(SYNC_LOST3);
+ }
#undef PIS
}
#endif
@@ -2973,6 +2976,7 @@ static void dispc_dump_regs(struct seq_file *s)
[OMAP_DSS_CHANNEL_LCD] = LCD,
[OMAP_DSS_CHANNEL_DIGIT]= TV,
[OMAP_DSS_CHANNEL_LCD2] = LCD2,
+ [OMAP_DSS_CHANNEL_LCD3] = LCD3,
};
const char *ovl_names[] = {
[OMAP_DSS_GFX] = GFX,
@@ -3005,6 +3009,10 @@ static void dispc_dump_regs(struct seq_file *s)
DUMPREG(DISPC_CONTROL2);
DUMPREG(DISPC_CONFIG2);
}
+ if (dss_has_feature(FEAT_MGR_LCD3)) {
+ DUMPREG(DISPC_CONTROL3);
+ DUMPREG(DISPC_CONFIG3);
+ }
#undef DUMPREG
@@ -3387,6 +3395,8 @@ static void print_irq_status(u32 status)
PIS(SYNC_LOST_DIGIT);
if (dss_has_feature(FEAT_MGR_LCD2))
PIS(SYNC_LOST2);
+ if (dss_has_feature(FEAT_MGR_LCD3))
+ PIS(SYNC_LOST3);
#undef PIS
printk(\n);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH] ARM: OMAP2PLUS: DSS: Disable LCD3 output when resetting DSS
The dispc_disable_outputs() function currently disables all LCD managers except
LCD3. This patch adds disabling functionality for LCD3 manager thereby
maintaining consistency of Display Subsystem for in case Display Controller is
reset when LCD3 manager is in use.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
arch/arm/mach-omap2/display.c | 25 +
1 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 5fb47a1..af1ed7d 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -37,6 +37,7 @@
#define DISPC_CONTROL 0x0040
#define DISPC_CONTROL2 0x0238
+#define DISPC_CONTROL3 0x0848
#define DISPC_IRQSTATUS0x0018
#define DSS_SYSCONFIG 0x10
@@ -52,6 +53,7 @@
#define EVSYNC_EVEN_IRQ_SHIFT 2
#define EVSYNC_ODD_IRQ_SHIFT 3
#define FRAMEDONE2_IRQ_SHIFT 22
+#define FRAMEDONE3_IRQ_SHIFT 30
#define FRAMEDONETV_IRQ_SHIFT 24
/*
@@ -376,7 +378,7 @@ int __init omap_display_init(struct omap_dss_board_info
*board_data)
static void dispc_disable_outputs(void)
{
u32 v, irq_mask = 0;
- bool lcd_en, digit_en, lcd2_en = false;
+ bool lcd_en, digit_en, lcd2_en = false, lcd3_en = false;
int i;
struct omap_dss_dispc_dev_attr *da;
struct omap_hwmod *oh;
@@ -405,7 +407,13 @@ static void dispc_disable_outputs(void)
lcd2_en = v LCD_EN_MASK;
}
- if (!(lcd_en | digit_en | lcd2_en))
+ /* store value of LCDENABLE for LCD3 */
+ if (da-manager_count 3) {
+ v = omap_hwmod_read(oh, DISPC_CONTROL3);
+ lcd3_en = v LCD_EN_MASK;
+ }
+
+ if (!(lcd_en | digit_en | lcd2_en | lcd3_en))
return; /* no managers currently enabled */
/*
@@ -426,10 +434,12 @@ static void dispc_disable_outputs(void)
if (lcd2_en)
irq_mask |= 1 FRAMEDONE2_IRQ_SHIFT;
+ if (lcd3_en)
+ irq_mask |= 1 FRAMEDONE3_IRQ_SHIFT;
/*
* clear any previous FRAMEDONE, FRAMEDONETV,
-* EVSYNC_EVEN/ODD or FRAMEDONE2 interrupts
+* EVSYNC_EVEN/ODD, FRAMEDONE2 or FRAMEDONE3 interrupts
*/
omap_hwmod_write(irq_mask, oh, DISPC_IRQSTATUS);
@@ -445,12 +455,19 @@ static void dispc_disable_outputs(void)
omap_hwmod_write(v, oh, DISPC_CONTROL2);
}
+ /* disable LCD3 manager */
+ if (da-manager_count 3) {
+ v = omap_hwmod_read(oh, DISPC_CONTROL3);
+ v = ~LCD_EN_MASK;
+ omap_hwmod_write(v, oh, DISPC_CONTROL3);
+ }
+
i = 0;
while ((omap_hwmod_read(oh, DISPC_IRQSTATUS) irq_mask) !=
irq_mask) {
i++;
if (i FRAMEDONE_IRQ_TIMEOUT) {
- pr_err(didn't get FRAMEDONE1/2 or TV interrupt\n);
+ pr_err(didn't get FRAMEDONE1/2/3 or TV interrupt\n);
break;
}
mdelay(1);
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New compiler warnings with v3.5-rc
On Thu, Jun 28, 2012 at 2:35 PM, Tero Kristo t-kri...@ti.com wrote: On Thu, 2012-06-28 at 02:47 -0600, Paul Walmsley wrote: Hi Tero, there are some new compiler warnings added in the v3.5-rc kernels: arch/arm/mach-omap2/twl-common.c:51:12: warning: 'twl_set_voltage' defined but not used arch/arm/mach-omap2/twl-common.c:57:12: warning: 'twl_get_voltage' defined but not used They only seem to appear on my N800 builds: http://www.pwsan.com/omap/testlogs/am35xx_devel_3.6/20120628014213/build/build_20120628011813_log.txt but it looks like I somehow am not doing a 2430-specific build yet, so they may be 24xx-common. Anyway they were probably added by: commit 49c008ecce1f9a549c12e8957668d60008ab0d79 Author: Tero Kristo t-kri...@ti.com Date: Mon Feb 20 12:26:08 2012 +0200 arm: omap3: twl: add external controllers for core voltage regulators Maybe you can put together a quick patch to fix these? Yea, I can do that. Can you provide your .config as reference? You can generate one quickly using these steps.. make omap2plus_defconfig scripts/config --disable ARCH_OMAP4 scripts/config --disable ARCH_OMAP3 make oldnoconfig make uImage ... and it should expose the warning. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On 28 June 2012 13:18, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-06-27 at 19:35 +0530, jaswinder.si...@linaro.org wrote:
From: Jassi Brar jaswinder.si...@linaro.org
We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C.
This could also help some cheapo displays that provide EDID reliably only
immediately after asserting HPD and not later.
Even with good displays, there is something in OMAPDSS that apparantly
messes up DDC occasionally while EDID is being read, giving the
operation stopped when reading edid error.
Btw, this is in nitpicking area, but what editor do you use? I find it
difficult to read text that is not formatted properly =). At least vim
formats text nicely with its formating commands.
Indeed a nitpick :)
I use vim and, iirc, checkpatch.pl gave 0 warning. Perhaps my poor
cmoposition. Please do tell how I could I make it more appealing to
you ?
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
There's a problem with this patch, which leaves a wrong EDID in the
cache: if you first have the cable connected and hdmi is enabled, you
then turn off the HDMI display device via sysfs, we do not go to
hdmi_check_hpd_state at all. The next time hdmi is enabled, we only get
the plug-in event, and thus EDID cache is never invalidated.
If the hdmi cable is not replugged during that period, I don't see why
would you want the EDID invalidated ?
--
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 2/7] mfd: omap: control: core system control driver
Hello,
On Thu, Jun 28, 2012 at 12:37 PM, Konstantin Baydarov
kbaida...@dev.rtsoft.ru wrote:
Hi.
On 06/28/2012 08:50 AM, Eduardo Valentin wrote:
Hello,
On Wed, Jun 27, 2012 at 10:04:54PM +0400, Konstantin Baydarov wrote:
This patch introduces a MFD core device driver for OMAP system control
module.
The control module allows software control of various static modes
supported by the device.
It is composed of two control submodules: general control module and device
(padconfiguration) control module.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts
file.
- omap-control-core: Control module is a built-in driver - added control
module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4.
Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module
IOMEM window, this allows access of SCM registers very early, for example
from omap_type()
- omap-control-core: Removed device pointer from omap-control-core API
arguments, becuase there can be only one instance control
module device.
- omap-control-core: removed omap_control_get, omap_control_readl,
omap_control_writel
- omap-control-core: added omap_control_status_read that is used early in
omap_type
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../devicetree/bindings/mfd/omap_control.txt | 44 +++
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/plat-omap/Kconfig | 4 +
drivers/mfd/Kconfig | 9 ++
drivers/mfd/Makefile | 1 +
drivers/mfd/omap-control-core.c | 131
include/linux/mfd/omap_control.h | 52
7 files changed, 242 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt
create mode 100644 drivers/mfd/omap-control-core.c
create mode 100644 include/linux/mfd/omap_control.h
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..46d5e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes
supported by
+the device. The control module controls the settings of various device
modules
+through register configuration and internal signals. It also controls the
pad
+configuration, pin functional multiplexing, and the routing of internal
signals
+(such as PRCM signals or DMA requests) to output pins configured for
hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+ - ti,omap3-control for OMAP3 support
+ - ti,omap4-control for OMAP4 support
+ - ti,omap5-control for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+ Should be ctrl_module_core;
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+ The bindings details of individual bandgap device can be found in:
+ Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+ The only required property for this child is:
+ - compatible = ti,omap4-control-usb;
+
+Examples:
+
+ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = ti,omap4-control;
+ ti,hwmods = ctrl_module_core;
+ bandgap {
+ compatible = ti,omap4460-bandgap;
You need to update the documentation if change the DT structure.
Ok.
+ interrupts = 0 126 4; /* talert */
+ ti,tshut-gpio = 86; /* tshut */
+ };
+ usb {
+ compatible = ti,omap4-usb-phy;
+ };
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4cf5142..c2ef07c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -52,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+ select ARCH_HAS_CONTROL_MODULE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..0f9b575 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+ bool
+ select MFD_OMAP_CONTROL
+
OK now I got what you meant in patch 0. Fine for me.
choice
prompt OMAP System Type
default
RE: [PATCH 0/3] Add device tree support to AM33XX SoC
Hi, Gentle remainder to this patch series. On Fri, Jun 22, 2012 at 15:10:46, AnilKumar, Chimata wrote: This patch series add device tree support for AM33XX SoC family. Initialy Hiremath Vaibhav submitted a patch for AM33XX devices based on omap3 family. Details at http://marc.info/?t=13268710722r=1w=2 AM33XX family is varied from omap3 family in these aspects like memory maps, peripheral base addresses and configuration parameters. In some cases we have to use a mix of omap3 and omap4 parameters. So a seperate am33xx.dtsi file is created for all the devices comes under am33xx family and revert of above patch is required. Two sepearte device tree source files are created (am335x-evm.dts and am335x-bone.dts) to add support for AM335X EVM and BeagleBone boards. Linux booting is tested on AM335X-EVM and BeagleBone boards. AnilKumar Ch (4): Revert arm/dts: Add support for TI AM335x EVM board arm/dts: Add initial DT support for AM33XX SoC family arm/dts: Add support for AM335x EVM arm/dts: Add support for AM335x BeagleBone .../devicetree/bindings/arm/omap/omap.txt |3 + arch/arm/boot/dts/am335x-bone.dts | 20 +++ arch/arm/boot/dts/am335x-evm.dts | 25 +-- arch/arm/boot/dts/am33xx.dtsi | 189 4 files changed, 215 insertions(+), 22 deletions(-) create mode 100644 arch/arm/boot/dts/am335x-bone.dts create mode 100644 arch/arm/boot/dts/am33xx.dtsi -- 1.7.9.5 Thanks AnilKumar -- 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 2/7] mfd: omap: control: core system control driver
Hello.
On 06/28/2012 01:49 PM, Valentin, Eduardo wrote:
Hello,
On Thu, Jun 28, 2012 at 12:37 PM, Konstantin Baydarov
kbaida...@dev.rtsoft.ru wrote:
Hi.
On 06/28/2012 08:50 AM, Eduardo Valentin wrote:
Hello,
On Wed, Jun 27, 2012 at 10:04:54PM +0400, Konstantin Baydarov wrote:
This patch introduces a MFD core device driver for OMAP system control
module.
The control module allows software control of various static modes
supported by the device.
It is composed of two control submodules: general control module and
device (padconfiguration) control module.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts
file.
- omap-control-core: Control module is a built-in driver - added control
module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4.
Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module
IOMEM window, this allows access of SCM registers very early, for example
from omap_type()
- omap-control-core: Removed device pointer from omap-control-core API
arguments, becuase there can be only one instance control
module device.
- omap-control-core: removed omap_control_get, omap_control_readl,
omap_control_writel
- omap-control-core: added omap_control_status_read that is used early in
omap_type
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../devicetree/bindings/mfd/omap_control.txt | 44 +++
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/plat-omap/Kconfig |4 +
drivers/mfd/Kconfig|9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 131
include/linux/mfd/omap_control.h | 52
7 files changed, 242 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt
create mode 100644 drivers/mfd/omap-control-core.c
create mode 100644 include/linux/mfd/omap_control.h
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..46d5e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes
supported by
+the device. The control module controls the settings of various device
modules
+through register configuration and internal signals. It also controls
the pad
+configuration, pin functional multiplexing, and the routing of internal
signals
+(such as PRCM signals or DMA requests) to output pins configured for
hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+ - ti,omap3-control for OMAP3 support
+ - ti,omap4-control for OMAP4 support
+ - ti,omap5-control for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+ Should be ctrl_module_core;
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+ The bindings details of individual bandgap device can be found in:
+ Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+ The only required property for this child is:
+- compatible = ti,omap4-control-usb;
+
+Examples:
+
+ctrl_module_core: ctrl_module_core@4a002000 {
+compatible = ti,omap4-control;
+ti,hwmods = ctrl_module_core;
+bandgap {
+compatible = ti,omap4460-bandgap;
You need to update the documentation if change the DT structure.
Ok.
+interrupts = 0 126 4; /* talert */
+ti,tshut-gpio = 86; /* tshut */
+};
+usb {
+compatible = ti,omap4-usb-phy;
+};
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4cf5142..c2ef07c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -52,6 +52,7 @@ config ARCH_OMAP4
select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
+select ARCH_HAS_CONTROL_MODULE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..0f9b575 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+bool
+select MFD_OMAP_CONTROL
+
OK now I got what you meant in patch 0. Fine for me.
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
On 28 June 2012 13:18, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Wed, 2012-06-27 at 19:35 +0530, jaswinder.si...@linaro.org wrote:
From: Jassi Brar jaswinder.si...@linaro.org
We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C.
This could also help some cheapo displays that provide EDID reliably only
immediately after asserting HPD and not later.
Even with good displays, there is something in OMAPDSS that apparantly
messes up DDC occasionally while EDID is being read, giving the
operation stopped when reading edid error.
Btw, this is in nitpicking area, but what editor do you use? I find it
difficult to read text that is not formatted properly =). At least vim
formats text nicely with its formating commands.
Indeed a nitpick :)
I use vim and, iirc, checkpatch.pl gave 0 warning. Perhaps my poor
cmoposition. Please do tell how I could I make it more appealing to
you ?
Like:
---
We can easily keep track of latest EDID from the display and hence avoid
expensive EDID re-reads over I2C. This could also help some cheapo displays
that provide EDID reliably only immediately after asserting HPD and not later.
Even with good displays, there is something in OMAPDSS that apparantly messes
up DDC occasionally while EDID is being read, giving the operation stopped
when reading edid error.
---
So basically two things: properly formatted paragraphs and an empty line
between paragraphs. With properly formatted I mean that that the text
goes from the beginning of the line to the end, so that the text fills
the whole line. This can be done easily in vim with first painting the
paragraph (or multiple paragraphs), and then then press g and w.
I think those simple rules make the text much easier to read.
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
There's a problem with this patch, which leaves a wrong EDID in the
cache: if you first have the cable connected and hdmi is enabled, you
then turn off the HDMI display device via sysfs, we do not go to
hdmi_check_hpd_state at all. The next time hdmi is enabled, we only get
the plug-in event, and thus EDID cache is never invalidated.
If the hdmi cable is not replugged during that period, I don't see why
would you want the EDID invalidated ?
I wasn't very clear with my comment.
When the display device is disabled, we're not listening to the hpd
interrupt anymore. So when it's disabled, the cable can be replugged and
the monitor changed, and the driver won't know about it. And so it'll
return the old EDID for the new monitor.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v3 2/7] mfd: omap: control: core system control driver
On 06/28/2012 02:12 PM, Konstantin Baydarov wrote: The interface(design) of omap-control-core.c has already been discussed many times :( Eduardo, in his patch set, suggested following design: - omap-control-core.c ioremaps SCM window and provide functions to read/write SCP register for bandgap and usb. IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb. So, my patch set introduces following design: - omap-control-core.c don't provide read/write functions for bandgap and usb. - bandgap and usb use their own private read/write functions - Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach. I mean: - Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped. So each call of ioremap in omap-control-core.c, bandgap and usb drivers returns the same virtual address. But the problem is that SCM memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach(when each driver remaps the same IOMEM). Another possible design is: - omap-control-core.c ioremaps and reserves SCM IOMEM window - omap-control-core.c exports omap_control_get_base(virtual base address is returned) to use in bandgap and usb_phy driver. - Bandgap and usb phy uses their own private read/write function. IIUC, this way was suggested by Tony. I guess It's better to settle the design(interface) of omap-control-core.c, bandgap and usb phy and then submit the next version of patch set. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On 28 June 2012 15:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
There's a problem with this patch, which leaves a wrong EDID in the
cache: if you first have the cable connected and hdmi is enabled, you
then turn off the HDMI display device via sysfs, we do not go to
hdmi_check_hpd_state at all. The next time hdmi is enabled, we only get
the plug-in event, and thus EDID cache is never invalidated.
If the hdmi cable is not replugged during that period, I don't see why
would you want the EDID invalidated ?
I wasn't very clear with my comment.
When the display device is disabled, we're not listening to the hpd
interrupt anymore. So when it's disabled, the cable can be replugged and
the monitor changed, and the driver won't know about it. And so it'll
return the old EDID for the new monitor.
If that could be a problem, then we already have some problem with
current omapdss.
I think among the first things, while enabling HDMI, should be to see
if there is really some display connected on the port i.e, HPD
asserted. Only if ti_hdmi_4xxx_detect() returned true, should we
proceed otherwise wait for HPQ irq.
Unconditionally invalidating edid really seems like a regression - we
impose atleast 50ms (edid read) as extra cost on
hdmi_check_hpd_state(), which kills half the purpose of this patch.
--
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: OMAP2: twl-common: fix compiler warnings
OMAP2 does not use the external voltage controller code for TWL, and
thus OMAP2 only compilation generates following warnings:
arch/arm/mach-omap2/twl-common.c:51: warning: 'twl_set_voltage' defined but not
used
arch/arm/mach-omap2/twl-common.c:57: warning: 'twl_get_voltage' defined but not
used
This patch moves the code in question behind ARCH specific flags and
eliminates these warnings.
Reported-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/twl-common.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 119d5a9..5447c13 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -48,6 +48,7 @@ static struct i2c_board_info __initdata
omap4_i2c1_board_info[] = {
},
};
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
static int twl_set_voltage(void *data, int target_uV)
{
struct voltagedomain *voltdm = (struct voltagedomain *)data;
@@ -59,6 +60,7 @@ static int twl_get_voltage(void *data)
struct voltagedomain *voltdm = (struct voltagedomain *)data;
return voltdm_get_voltage(voltdm);
}
+#endif
void __init omap_pmic_init(int bus, u32 clkrate,
const char *pmic_type, int pmic_irq,
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] OMAPDSS: Cleanup implementation of LCD channels
On Thu, 2012-06-28 at 15:10 +0530, Chandrabhanu Mahapatra wrote:
The current implementation of LCD channels and managers consists of a number
of
if-else construct which has been replaced by a simpler interface. A constant
structure mgr_desc has been created in Display Controller (DISPC) module. The
mgr_desc contains for each channel its name, irqs and is initialized one time
with all registers and their corresponding fields to be written to enable
various features of Display Subsystem. This structure is later used by various
functions of DISPC which simplifies the further implementation of LCD channels
and its corresponding managers.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 233
+
drivers/video/omap2/dss/dsi.c |6 +-
drivers/video/omap2/dss/dss.h |6 +
drivers/video/omap2/dss/manager.c | 12 +--
4 files changed, 121 insertions(+), 136 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4749ac3..6c16b81 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -57,6 +57,8 @@
#define DISPC_MAX_NR_ISRS8
+#define DISPC_MGR_FLD_MAX9
You could have this in the enum mgr_ref_fields, as a last entry. Then
it'll automatically have the value 9, and will adjust automatically when
we add new fields. And actually MAX is not quite right. MAX would be
8, as that's the maximum value for the vields. NUM is perhaps more
correct.
+
struct omap_dispc_isr_data {
omap_dispc_isr_tisr;
void*arg;
@@ -119,6 +121,78 @@ enum omap_color_component {
DISPC_COLOR_COMPONENT_UV= 1 1,
};
+enum mgr_reg_fields {
+ DISPC_MGR_FLD_ENABLE,
+ DISPC_MGR_FLD_STNTFT,
+ DISPC_MGR_FLD_GO,
+ DISPC_MGR_FLD_TFTDATALINES,
+ DISPC_MGR_FLD_STALLMODE,
+ DISPC_MGR_FLD_TCKENABLE,
+ DISPC_MGR_FLD_TCKSELECTION,
+ DISPC_MGR_FLD_CPR,
+ DISPC_MGR_FLD_FIFOHANDCHECK,
+};
+
+static const struct {
+ const char *name;
+ u32 vsync_irq;
+ u32 framedone_irq;
+ u32 sync_lost_irq;
+ struct reg_field reg_desc[DISPC_MGR_FLD_MAX];
+} mgr_desc[] = {
+ [OMAP_DSS_CHANNEL_LCD] = {
+ .name = LCD,
+ .vsync_irq = DISPC_IRQ_VSYNC,
+ .framedone_irq = DISPC_IRQ_FRAMEDONE,
+ .sync_lost_irq = DISPC_IRQ_SYNC_LOST,
+ .reg_desc = {
+ [DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL, 0,
0 },
+ [DISPC_MGR_FLD_STNTFT] = { DISPC_CONTROL, 3,
3 },
+ [DISPC_MGR_FLD_GO] = { DISPC_CONTROL, 5,
5 },
+ [DISPC_MGR_FLD_TFTDATALINES]= { DISPC_CONTROL, 9,
8 },
+ [DISPC_MGR_FLD_STALLMODE] = { DISPC_CONTROL, 11,
11 },
+ [DISPC_MGR_FLD_TCKENABLE] = { DISPC_CONFIG, 10,
10 },
+ [DISPC_MGR_FLD_TCKSELECTION]= { DISPC_CONFIG, 11,
11 },
+ [DISPC_MGR_FLD_CPR] = { DISPC_CONFIG, 15,
15 },
+ [DISPC_MGR_FLD_FIFOHANDCHECK] = { DISPC_CONFIG, 16,
16 },
+ },
+ },
+ [OMAP_DSS_CHANNEL_DIGIT] = {
+ .name = DIGIT,
+ .vsync_irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN,
+ .framedone_irq = DISPC_IRQ_FRAMEDONETV,
There's a problem with this one. FRAMEDONETV is a new thing, appeared in
omap4. So for this we need a system to select the data depending on the
DSS version.
I suggest you remove the framedone_irq entry for now, and keep the old
code to handle the framedone irq. Let's add it later when we can handle
the differences between omap versions.
Or actually, looking at the code, perhaps you can keep the framedone_irq
field, but set it to 0 for DIGIT mgr. This would keep the functionality
the same as it is now, because there's only one place in dispc.c where
we use FRAMEDONETV, and your patch doesn't touch it. In other places we
presume that TV out does not have FRAMEDONE interrupt (i.e. the irq
number is 0).
+ .sync_lost_irq = DISPC_IRQ_SYNC_LOST_DIGIT,
+ .reg_desc = {
+ [DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL, 1,
1 },
+ [DISPC_MGR_FLD_STNTFT] = { },
+ [DISPC_MGR_FLD_GO] = { DISPC_CONTROL, 6,
6 },
+ [DISPC_MGR_FLD_TFTDATALINES]= { },
+ [DISPC_MGR_FLD_STALLMODE] = { },
+ [DISPC_MGR_FLD_TCKENABLE] = { DISPC_CONFIG, 12,
12 },
+ [DISPC_MGR_FLD_TCKSELECTION]= { DISPC_CONFIG, 13,
13 },
+ [DISPC_MGR_FLD_CPR] = { },
+
Re: [PATCH v3 2/7] mfd: omap: control: core system control driver
Hello, On Thu, Jun 28, 2012 at 1:26 PM, Konstantin Baydarov kbaida...@dev.rtsoft.ru wrote: On 06/28/2012 02:12 PM, Konstantin Baydarov wrote: The interface(design) of omap-control-core.c has already been discussed many times :( Eduardo, in his patch set, suggested following design: - omap-control-core.c ioremaps SCM window and provide functions to read/write SCP register for bandgap and usb. IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb. So, my patch set introduces following design: - omap-control-core.c don't provide read/write functions for bandgap and usb. - bandgap and usb use their own private read/write functions - Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach. I mean: - Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped. So each call of ioremap in omap-control-core.c, bandgap and usb drivers returns the same virtual address. But the problem is that SCM memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach(when each driver remaps the same IOMEM). Another possible design is: - omap-control-core.c ioremaps and reserves SCM IOMEM window - omap-control-core.c exports omap_control_get_base(virtual base address is returned) to use in bandgap and usb_phy driver. - Bandgap and usb phy uses their own private read/write function. IIUC, this way was suggested by Tony. Well I understood slightly different :-) I think the point is not really where to put the access functions, but to have each driver handling a separate part of the the io window. As I said before, so that they don't access each other io area. If you have 1 io window, for the above mentioned constraint, you won't protect anything. So, in that sense, it doesn't make much difference if you have access functions in core, or in the children, as they are all sharing the same io window. Of course, in case we put only 1 io window, for me it is safer if that window is managed in only one place, instead of several places. The question is then, can we split the io area into smaller windows for each children? Considering the children registers are not contiguous :-(. In theory we can put several entries in the 'reg' DT property, but that becomes a bit messy as it will change depending on OMAP version. Anyways, if we split the scm io window into several io smaller areas/chunks, then it makes sense to have access functions in each children. I guess It's better to settle the design(interface) of omap-control-core.c, bandgap and usb phy and then submit the next version of patch set. Agreed. Here. We need to decide how to have this design and stick to it. -- Eduardo Valentin -- 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 2/7] mfd: omap: control: core system control driver
Hello again, On Thu, Jun 28, 2012 at 1:51 PM, Valentin, Eduardo eduardo.valen...@ti.com wrote: Hello, On Thu, Jun 28, 2012 at 1:26 PM, Konstantin Baydarov kbaida...@dev.rtsoft.ru wrote: On 06/28/2012 02:12 PM, Konstantin Baydarov wrote: The interface(design) of omap-control-core.c has already been discussed many times :( Eduardo, in his patch set, suggested following design: - omap-control-core.c ioremaps SCM window and provide functions to read/write SCP register for bandgap and usb. IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb. So, my patch set introduces following design: - omap-control-core.c don't provide read/write functions for bandgap and usb. - bandgap and usb use their own private read/write functions - Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach. I mean: - Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped. So each call of ioremap in omap-control-core.c, bandgap and usb drivers returns the same virtual address. But the problem is that SCM memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach(when each driver remaps the same IOMEM). Another possible design is: - omap-control-core.c ioremaps and reserves SCM IOMEM window - omap-control-core.c exports omap_control_get_base(virtual base address is returned) to use in bandgap and usb_phy driver. - Bandgap and usb phy uses their own private read/write function. IIUC, this way was suggested by Tony. Well I understood slightly different :-) I think the point is not really where to put the access functions, but to have each driver handling a separate part of the the io window. As I said before, so that they don't access each other io area. If you have 1 io window, for the above mentioned constraint, you won't protect anything. So, in that sense, it doesn't make much difference if you have access functions in core, or in the children, as they are all sharing the same io window. Of course, in case we put only 1 io window, for me it is safer if that window is managed in only one place, instead of several places. The question is then, can we split the io area into smaller windows for each children? Considering the children registers are not contiguous :-(. In theory we can put several entries in the 'reg' DT property, but that becomes a bit messy as it will change depending on OMAP version. Anyways, if we split the scm io window into several io smaller areas/chunks, then it makes sense to have access functions in each children. I guess It's better to settle the design(interface) of omap-control-core.c, bandgap and usb phy and then submit the next version of patch set. Agreed. Here. We need to decide how to have this design and stick to it. Once the design is agreed, the series can probably be split into parts, so we can have the scm core and its children worked separately -- Eduardo Valentin -- Eduardo Valentin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On 28 June 2012 16:17, Jassi Brar jaswinder.si...@linaro.org wrote:
On 28 June 2012 15:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct
hdmi_ip_data *ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
There's a problem with this patch, which leaves a wrong EDID in the
cache: if you first have the cable connected and hdmi is enabled, you
then turn off the HDMI display device via sysfs, we do not go to
hdmi_check_hpd_state at all. The next time hdmi is enabled, we only get
the plug-in event, and thus EDID cache is never invalidated.
If the hdmi cable is not replugged during that period, I don't see why
would you want the EDID invalidated ?
I wasn't very clear with my comment.
When the display device is disabled, we're not listening to the hpd
interrupt anymore. So when it's disabled, the cable can be replugged and
the monitor changed, and the driver won't know about it. And so it'll
return the old EDID for the new monitor.
If that could be a problem, then we already have some problem with
current omapdss.
I think among the first things, while enabling HDMI, should be to see
if there is really some display connected on the port i.e, HPD
asserted. Only if ti_hdmi_4_detect() returned true, should we
proceed otherwise wait for HPQ irq.
Unconditionally invalidating edid really seems like a regression - we
impose atleast 50ms (edid read) as extra cost on
hdmi_check_hpd_state(), which kills half the purpose of this patch.
Sorry a correction. Reading detect() won't work. I suggest we keep HPD
IRQ enabled for the lifetime of the driver.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: only call smp_send_stop() on SMP
On Thu, Jun 28, 2012 at 10:06:23AM +0300, Pantelis Antoniou wrote: Err, There was a patch been sent in response that did exactly as you asked. http://lkml.indiana.edu/hypermail/linux/kernel/1205.3/00433.html Regards Obviously it was missed, and no one bothered to re-send it. Yes, it looks fine. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On Thu, 2012-06-28 at 16:17 +0530, Jassi Brar wrote: On 28 June 2012 15:44, Tomi Valkeinen tomi.valkei...@ti.com wrote: When the display device is disabled, we're not listening to the hpd interrupt anymore. So when it's disabled, the cable can be replugged and the monitor changed, and the driver won't know about it. And so it'll return the old EDID for the new monitor. If that could be a problem, then we already have some problem with current omapdss. I think among the first things, while enabling HDMI, should be to see if there is really some display connected on the port i.e, HPD asserted. Only if ti_hdmi_4xxx_detect() returned true, should we proceed otherwise wait for HPQ irq. I'm not sure I understand. The HDMI driver does just that. It calls hdmi_check_hpd_state when it's being enabled to see if there's a display connected. Unconditionally invalidating edid really seems like a regression - we impose atleast 50ms (edid read) as extra cost on hdmi_check_hpd_state(), which kills half the purpose of this patch. If the HDMI hardware is turned off, we should unconditionally invalidate the EDID. We have no way to keep track if the same monitor is kept plugged in or not. So what exactly is the purpose of this patch, what kind of scenario? I thought it's to cache the EDID, so that if it will be read multiple times while the same monitor is connected, we'll just return the cached value. Of course, I don't know why the upper layers would read the EDID multiple times, because I think they should read it only once. So perhaps I'm either not understanding something, or it's the omapdrm layer that should be fixed? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
On 28 June 2012 16:17, Jassi Brar jaswinder.si...@linaro.org wrote:
On 28 June 2012 15:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct
hdmi_ip_data *ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
There's a problem with this patch, which leaves a wrong EDID in the
cache: if you first have the cable connected and hdmi is enabled, you
then turn off the HDMI display device via sysfs, we do not go to
hdmi_check_hpd_state at all. The next time hdmi is enabled, we only get
the plug-in event, and thus EDID cache is never invalidated.
If the hdmi cable is not replugged during that period, I don't see why
would you want the EDID invalidated ?
I wasn't very clear with my comment.
When the display device is disabled, we're not listening to the hpd
interrupt anymore. So when it's disabled, the cable can be replugged and
the monitor changed, and the driver won't know about it. And so it'll
return the old EDID for the new monitor.
If that could be a problem, then we already have some problem with
current omapdss.
I think among the first things, while enabling HDMI, should be to see
if there is really some display connected on the port i.e, HPD
asserted. Only if ti_hdmi_4_detect() returned true, should we
proceed otherwise wait for HPQ irq.
Unconditionally invalidating edid really seems like a regression - we
impose atleast 50ms (edid read) as extra cost on
hdmi_check_hpd_state(), which kills half the purpose of this patch.
Sorry a correction. Reading detect() won't work. I suggest we keep HPD
IRQ enabled for the lifetime of the driver.
Ok, I see. But that's not acceptable. It would require us to keep the
TPD12S015 always powered and enabled. Even if you're not interested in
using HDMI at all.
For this to work like you want we need a bigger restructuring of HDMI
and partly omapdss also. Currently we have just one big enabled or
disabled state. We need multiple states. Probably something like:
- disabled, everything totally off
- low power, hotplug detection enabled
- powered on, but no video
- video enabled
Been long in my mind, but I'm not very familiar with HDMI so I could get
my simple prototypes to work when I tried something like this once.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 1/4] OMAPDSS: Cleanup implementation of LCD channels
On Thursday 28 June 2012 04:20 PM, Tomi Valkeinen wrote:
On Thu, 2012-06-28 at 15:10 +0530, Chandrabhanu Mahapatra wrote:
The current implementation of LCD channels and managers consists of a number
of
if-else construct which has been replaced by a simpler interface. A constant
structure mgr_desc has been created in Display Controller (DISPC) module. The
mgr_desc contains for each channel its name, irqs and is initialized one
time
with all registers and their corresponding fields to be written to enable
various features of Display Subsystem. This structure is later used by
various
functions of DISPC which simplifies the further implementation of LCD
channels
and its corresponding managers.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 233
+
drivers/video/omap2/dss/dsi.c |6 +-
drivers/video/omap2/dss/dss.h |6 +
drivers/video/omap2/dss/manager.c | 12 +--
4 files changed, 121 insertions(+), 136 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
b/drivers/video/omap2/dss/dispc.c
index 4749ac3..6c16b81 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -57,6 +57,8 @@
#define DISPC_MAX_NR_ISRS 8
+#define DISPC_MGR_FLD_MAX 9
You could have this in the enum mgr_ref_fields, as a last entry. Then
it'll automatically have the value 9, and will adjust automatically when
we add new fields. And actually MAX is not quite right. MAX would be
8, as that's the maximum value for the vields. NUM is perhaps more
correct.
Its really a clever idea to have it as the last field of enum
mgr_ref_fields. To make it distinct from other fields I can add a
comment on top of it saying its for count of above fields or I am fine
with names as DISPC_MGR_FLD_COUNT / NUM.
+
struct omap_dispc_isr_data {
omap_dispc_isr_tisr;
void*arg;
@@ -119,6 +121,78 @@ enum omap_color_component {
DISPC_COLOR_COMPONENT_UV= 1 1,
};
+enum mgr_reg_fields {
+DISPC_MGR_FLD_ENABLE,
+DISPC_MGR_FLD_STNTFT,
+DISPC_MGR_FLD_GO,
+DISPC_MGR_FLD_TFTDATALINES,
+DISPC_MGR_FLD_STALLMODE,
+DISPC_MGR_FLD_TCKENABLE,
+DISPC_MGR_FLD_TCKSELECTION,
+DISPC_MGR_FLD_CPR,
+DISPC_MGR_FLD_FIFOHANDCHECK,
+};
+
+static const struct {
+const char *name;
+u32 vsync_irq;
+u32 framedone_irq;
+u32 sync_lost_irq;
+struct reg_field reg_desc[DISPC_MGR_FLD_MAX];
+} mgr_desc[] = {
+[OMAP_DSS_CHANNEL_LCD] = {
+.name = LCD,
+.vsync_irq = DISPC_IRQ_VSYNC,
+.framedone_irq = DISPC_IRQ_FRAMEDONE,
+.sync_lost_irq = DISPC_IRQ_SYNC_LOST,
+.reg_desc = {
+[DISPC_MGR_FLD_ENABLE] = { DISPC_CONTROL, 0,
0 },
+[DISPC_MGR_FLD_STNTFT] = { DISPC_CONTROL, 3,
3 },
+[DISPC_MGR_FLD_GO] = { DISPC_CONTROL, 5,
5 },
+[DISPC_MGR_FLD_TFTDATALINES]= { DISPC_CONTROL, 9,
8 },
+[DISPC_MGR_FLD_STALLMODE] = { DISPC_CONTROL, 11,
11 },
+[DISPC_MGR_FLD_TCKENABLE] = { DISPC_CONFIG, 10,
10 },
+[DISPC_MGR_FLD_TCKSELECTION]= { DISPC_CONFIG, 11,
11 },
+[DISPC_MGR_FLD_CPR] = { DISPC_CONFIG, 15,
15 },
+[DISPC_MGR_FLD_FIFOHANDCHECK] = { DISPC_CONFIG, 16,
16 },
+},
+},
+[OMAP_DSS_CHANNEL_DIGIT] = {
+.name = DIGIT,
+.vsync_irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN,
+.framedone_irq = DISPC_IRQ_FRAMEDONETV,
There's a problem with this one. FRAMEDONETV is a new thing, appeared in
omap4. So for this we need a system to select the data depending on the
DSS version.
I suggest you remove the framedone_irq entry for now, and keep the old
code to handle the framedone irq. Let's add it later when we can handle
the differences between omap versions.
Or actually, looking at the code, perhaps you can keep the framedone_irq
field, but set it to 0 for DIGIT mgr. This would keep the functionality
the same as it is now, because there's only one place in dispc.c where
we use FRAMEDONETV, and your patch doesn't touch it. In other places we
presume that TV out does not have FRAMEDONE interrupt (i.e. the irq
number is 0).
The purpose of FRAMEDONETV IRQ as seen from dispc_mgr_enable_digit_out()
looks as to interrupt when active frame related to HDMI is done and so
DISPC is disabled. I think I misinterpreted and used it here. Can
please explain the exact purpose of DISPC_IRQ_FRAMEDONETV?
+.sync_lost_irq = DISPC_IRQ_SYNC_LOST_DIGIT,
+.reg_desc = {
+[DISPC_MGR_FLD_ENABLE] =
Re: [PATCH 1/4] OMAPDSS: Cleanup implementation of LCD channels
On Thu, 2012-06-28 at 16:49 +0530, Chandrabhanu Mahapatra wrote:
On Thursday 28 June 2012 04:20 PM, Tomi Valkeinen wrote:
On Thu, 2012-06-28 at 15:10 +0530, Chandrabhanu Mahapatra wrote:
+ [OMAP_DSS_CHANNEL_DIGIT] = {
+ .name = DIGIT,
+ .vsync_irq = DISPC_IRQ_EVSYNC_ODD | DISPC_IRQ_EVSYNC_EVEN,
+ .framedone_irq = DISPC_IRQ_FRAMEDONETV,
There's a problem with this one. FRAMEDONETV is a new thing, appeared in
omap4. So for this we need a system to select the data depending on the
DSS version.
I suggest you remove the framedone_irq entry for now, and keep the old
code to handle the framedone irq. Let's add it later when we can handle
the differences between omap versions.
Or actually, looking at the code, perhaps you can keep the framedone_irq
field, but set it to 0 for DIGIT mgr. This would keep the functionality
the same as it is now, because there's only one place in dispc.c where
we use FRAMEDONETV, and your patch doesn't touch it. In other places we
presume that TV out does not have FRAMEDONE interrupt (i.e. the irq
number is 0).
The purpose of FRAMEDONETV IRQ as seen from dispc_mgr_enable_digit_out()
looks as to interrupt when active frame related to HDMI is done and so
DISPC is disabled. I think I misinterpreted and used it here. Can
please explain the exact purpose of DISPC_IRQ_FRAMEDONETV?
Yes, FRAMEDONE, for both LCD and TV outputs tells us that the DISPC
output has finished sending the last frame, when the output is being
disabled. So your use here is correct, except that the interrupt is not
present on omap2/3. Thus we cannot have it in this common table.
If you set the field to 0 in this table, everything should work as
before. If you look at the dispc_mgr_get_framedone_irq() code, you see
that it returns 0 for DIGIT channel.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On Thu, 2012-06-28 at 14:10 +0300, Tomi Valkeinen wrote: On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote: Sorry a correction. Reading detect() won't work. I suggest we keep HPD IRQ enabled for the lifetime of the driver. Ok, I see. But that's not acceptable. It would require us to keep the TPD12S015 always powered and enabled. Even if you're not interested in using HDMI at all. Btw, a bigger problem that I see is how we have to do read_edid() (and detect(), if I recall correctly): we enable the whole video pipeline and output. We should only enable enough of the HW to be able to read the EDID or read the HPD GPIO. I've noticed that this leads to sync losts quite easily, as we switch the hdmi output on and off quickly multiple times. I couldn't figure out why the sync losts happen though, and I did try quite many different combinations how to handle it. Tomi signature.asc Description: This is a digitally signed message part
[PATCH v1 00/11] omap: musb: Add device tree support
This patch series adds device tree support for MUSB and device tree support for all the related modules to get MUSB working in OMAP platform. A new omap-usb2 phy driver has been added (with only dt suppport) to perform phy configurations. Previously this configuration was performed by twl6030, using pdata function pointers. With the addition of omap-usb2 to perform phy configurations, twl6030 is made as a comparator driver to detect VBUS and ID events and notify it to the glue layer. musb core is _NOT_ yet converted to support device tree support as it would need lot of driver re-design because of its enormous use of function pointers. That will be in _TO DO_ list. Changes from RFC: Removed the dependency on [RFC PATCH 00/11] OMAP System Control Module. Writing to control module register is now handled in otg driver itself. Once the system control module driver get upstreamed, I'll send a patch to make use of API's in control module driver to write to control module register. This series was developed on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git xceiv This patch series depends on [RFC PATCH v2 0/2] omap: add ocp2scp as a misc driver. there is still some discussion on where to place the ocp2scp driver. Once that gets finalized, I'll resend this patch series again with that adaptaion. Performed MUSB device mode testing on OMAP4 panda, OMAP4 SDP and OMAP3 beagle. Kishon Vijay Abraham I (11): drivers: usb: otg: add a new driver for omap usb2 phy arm/dts: omap: Add omap-usb2 dt data drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2 arm: omap: hwmod: add a new addr space in otg for writing to control module drivers: usb: twl6030: Add dt support for twl6030 usb arm/dts: Add twl6030-usb data drivers: usb: twl4030: Add device tree support for twl4030 usb arm/dts: Add twl4030-usb data drivers: usb: musb: Add device tree support for omap musb glue arm/dts: omap: Add usb_otg and glue data arm: omap: phy: remove unused functions from omap-phy-internal.c .../devicetree/bindings/misc/omap-ocp2scp.txt |3 + Documentation/devicetree/bindings/usb/omap-usb.txt | 48 .../devicetree/bindings/usb/twl-usb.txt| 37 +++ arch/arm/boot/dts/omap3-beagle.dts |6 + arch/arm/boot/dts/omap3-evm.dts|6 + arch/arm/boot/dts/omap3.dtsi |8 + arch/arm/boot/dts/omap4-panda.dts |6 + arch/arm/boot/dts/omap4-sdp.dts|6 + arch/arm/boot/dts/omap4.dtsi | 13 + arch/arm/boot/dts/twl4030.dtsi | 21 ++ arch/arm/boot/dts/twl6030.dtsi |7 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 + arch/arm/mach-omap2/omap_phy_internal.c| 138 -- arch/arm/mach-omap2/twl-common.c |5 - arch/arm/mach-omap2/usb-musb.c |3 - drivers/usb/musb/omap2430.c| 104 +++- drivers/usb/musb/omap2430.h|9 + drivers/usb/otg/Kconfig| 10 + drivers/usb/otg/Makefile |1 + drivers/usb/otg/omap-usb2.c| 273 drivers/usb/otg/twl4030-usb.c | 28 ++- drivers/usb/otg/twl6030-usb.c | 157 include/linux/usb/omap_usb.h | 45 include/linux/usb/phy_companion.h | 34 +++ 24 files changed, 701 insertions(+), 272 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt create mode 100644 drivers/usb/otg/omap-usb2.c create mode 100644 include/linux/usb/omap_usb.h create mode 100644 include/linux/usb/phy_companion.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 01/11] drivers: usb: otg: add a new driver for omap usb2 phy
All phy related programming like enabling/disabling the clocks, powering
on/off the phy is taken care of by this driver. It is also used for OTG
related functionality like srp.
This also includes device tree support for usb2 phy driver and
the documentation with device tree binding information is updated.
Currently writing to control module register is taken care in this
driver which will be removed once the control module driver is in place.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/misc/omap-ocp2scp.txt |3 +
Documentation/devicetree/bindings/usb/omap-usb.txt | 16 ++
drivers/usb/otg/Kconfig| 10 +
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap-usb2.c| 273
include/linux/usb/omap_usb.h | 45
include/linux/usb/phy_companion.h | 34 +++
7 files changed, 382 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/omap-usb.txt
create mode 100644 drivers/usb/otg/omap-usb2.c
create mode 100644 include/linux/usb/omap_usb.h
create mode 100644 include/linux/usb/phy_companion.h
diff --git a/Documentation/devicetree/bindings/misc/omap-ocp2scp.txt
b/Documentation/devicetree/bindings/misc/omap-ocp2scp.txt
index e9391d8..d1c7480 100644
--- a/Documentation/devicetree/bindings/misc/omap-ocp2scp.txt
+++ b/Documentation/devicetree/bindings/misc/omap-ocp2scp.txt
@@ -7,3 +7,6 @@ properties:
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp
+- usb2phy :
+ The binding details of usb2phy can be found in:
+ Documentation/devicetree/bindings/usb/omap-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
new file mode 100644
index 000..80a28c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -0,0 +1,16 @@
+OMAP USB PHY
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be ti,omap-usb2
+ - reg : Address and length of the register set for the device. Also
+add the address of control module dev conf register until a driver for
+control module is added
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@0x4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58;
+};
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..c751db7 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,16 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP_USB2
+ tristate OMAP USB2 PHY Driver
+ depends on OMAP_OCP2SCP
+ select USB_OTG_UTILS
+ help
+ Enable this to support the transceiver that is part of SOC. This
+ driver takes care of all the PHY functionality apart from comparator.
+ The USB OTG controller communicates with the comparator using this
+ driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..2c2a3ca 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP_USB2)+= omap-usb2.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap-usb2.c b/drivers/usb/otg/omap-usb2.c
new file mode 100644
index 000..58bb3fe
--- /dev/null
+++ b/drivers/usb/otg/omap-usb2.c
@@ -0,0 +1,273 @@
+/*
+ * omap-usb2.c - USB PHY, talking to musb controller in OMAP.
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I kis...@ti.com
+ *
+ * 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.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/io.h
+#include linux/usb/omap_usb.h
+#include linux/usb/phy_companion.h
+#include linux/clk.h
+#include linux/err.h
+#include
[PATCH v1 02/11] arm/dts: omap: Add omap-usb2 dt data
Add omap-usb2 data node in omap4 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap4.dtsi |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index bda5df3..4d2dcc1 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -279,6 +279,11 @@
#size-cells = 1;
ranges;
ti,hwmods = ocp2scp_usb_phy;
+ usb2phy@0x4a0ad080 {
+ compatible = ti,omap-usb2;
+ reg = 0x4a0ad080 0x58,
+ 0x4a002300 0x1;
+ };
};
};
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 04/11] arm: omap: hwmod: add a new addr space in otg for writing to control module
The mailbox register for usb otg in omap is present in control module.
On detection of any events VBUS or ID, this register should be written
to send the notification to musb core.
Till we have a separate control module driver to write to control module,
omap2430 will handle the register writes to control module by itself. So
a new address space to represent this control module register is added
to usb_otg_hs.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 249ff76..2c28754 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5897,6 +5897,11 @@ static struct omap_hwmod_addr_space
omap44xx_usb_otg_hs_addrs[] = {
.pa_end = 0x4a0ab003,
.flags = ADDR_TYPE_RT
},
+ {
+ .pa_start = 0x4a00233c,
+ .pa_end = 0x4a00233f,
+ .flags = ADDR_TYPE_RT
+ },
{ }
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 08/11] arm/dts: Add twl4030-usb data
Add twl4030-usb data node in twl4030 device tree file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/twl4030.dtsi | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 22f4d13..66534a3 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -37,6 +37,18 @@
regulator-max-microvolt = 315;
};
+ vusb1v5: regulator@3 {
+ compatible = ti,twl4030-vusb1v5;
+ };
+
+ vusb1v8: regulator@4 {
+ compatible = ti,twl4030-vusb1v8;
+ };
+
+ vusb3v1: regulator@5 {
+ compatible = ti,twl4030-vusb3v1;
+ };
+
twl_gpio: gpio {
compatible = ti,twl4030-gpio;
gpio-controller;
@@ -44,4 +56,13 @@
interrupt-controller;
#interrupt-cells = 1;
};
+
+ twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ usb1v5-supply = vusb1v5;
+ usb1v8-supply = vusb1v8;
+ usb3v1-supply = vusb3v1;
+ usb_mode = 1;
+ };
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 06/11] arm/dts: Add twl6030-usb data
Add twl6030-usb data node in twl6030 device tree file
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/twl6030.dtsi |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 3b2f351..6526366 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -83,4 +83,11 @@
clk32kg: regulator@12 {
compatible = ti,twl6030-clk32kg;
};
+
+ twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+ vusb-supply = vusb;
+ };
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 10/11] arm/dts: omap: Add usb_otg and glue data
Add usb otg data node in omap4/omap3 device tree file. Also update
the node with board specific setting in omapx-board.dts file.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts |6 ++
arch/arm/boot/dts/omap3-evm.dts|6 ++
arch/arm/boot/dts/omap3.dtsi |8
arch/arm/boot/dts/omap4-panda.dts |6 ++
arch/arm/boot/dts/omap4-sdp.dts|6 ++
arch/arm/boot/dts/omap4.dtsi |8
6 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 5b4506c..f3d7076 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -67,3 +67,9 @@
mmc3 {
status = disable;
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index 2eee16e..8963b3d 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -18,3 +18,9 @@
reg = 0x8000 0x1000; /* 256 MB */
};
};
+
+usb_otg_hs {
+ interface_type = 0;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99474fa..2f565d6 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -215,5 +215,13 @@
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc3;
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 1efe0c5..0825fa7 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -89,3 +89,9 @@
ti,non-removable;
bus-width = 4;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index d08c4d1..5244d51 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -158,3 +158,9 @@
bus-width = 4;
ti,non-removable;
};
+
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 4d2dcc1..bc7b3c3 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -285,5 +285,13 @@
0x4a002300 0x1;
};
};
+
+ usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+ };
};
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 11/11] arm: omap: phy: remove unused functions from omap-phy-internal.c
All the unnessary functions in omap-phy-internal is removed.
These functionality are now handled by omap-usb2 phy driver.
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_phy_internal.c | 138 ---
arch/arm/mach-omap2/twl-common.c|5 -
arch/arm/mach-omap2/usb-musb.c |3 -
3 files changed, 0 insertions(+), 146 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_phy_internal.c
b/arch/arm/mach-omap2/omap_phy_internal.c
index 4c90477..0c610b4 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -31,144 +31,6 @@
#include plat/usb.h
#include control.h
-/* OMAP control module register for UTMI PHY */
-#define CONTROL_DEV_CONF 0x300
-#define PHY_PD 0x1
-
-#define USBOTGHS_CONTROL 0x33c
-#defineAVALID BIT(0)
-#defineBVALID BIT(1)
-#defineVBUSVALID BIT(2)
-#defineSESSEND BIT(3)
-#defineIDDIG BIT(4)
-
-static struct clk *phyclk, *clk48m, *clk32k;
-static void __iomem *ctrl_base;
-static int usbotghs_control;
-
-int omap4430_phy_init(struct device *dev)
-{
- ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K);
- if (!ctrl_base) {
- pr_err(control module ioremap failed\n);
- return -ENOMEM;
- }
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- if (!dev) {
- iounmap(ctrl_base);
- return 0;
- }
-
- phyclk = clk_get(dev, ocp2scp_usb_phy_ick);
- if (IS_ERR(phyclk)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_ick\n);
- iounmap(ctrl_base);
- return PTR_ERR(phyclk);
- }
-
- clk48m = clk_get(dev, ocp2scp_usb_phy_phy_48m);
- if (IS_ERR(clk48m)) {
- dev_err(dev, cannot clk_get ocp2scp_usb_phy_phy_48m\n);
- clk_put(phyclk);
- iounmap(ctrl_base);
- return PTR_ERR(clk48m);
- }
-
- clk32k = clk_get(dev, usb_phy_cm_clk32k);
- if (IS_ERR(clk32k)) {
- dev_err(dev, cannot clk_get usb_phy_cm_clk32k\n);
- clk_put(phyclk);
- clk_put(clk48m);
- iounmap(ctrl_base);
- return PTR_ERR(clk32k);
- }
- return 0;
-}
-
-int omap4430_phy_set_clk(struct device *dev, int on)
-{
- static int state;
-
- if (on !state) {
- /* Enable the phy clocks */
- clk_enable(phyclk);
- clk_enable(clk48m);
- clk_enable(clk32k);
- state = 1;
- } else if (state) {
- /* Disable the phy clocks */
- clk_disable(phyclk);
- clk_disable(clk48m);
- clk_disable(clk32k);
- state = 0;
- }
- return 0;
-}
-
-int omap4430_phy_power(struct device *dev, int ID, int on)
-{
- if (on) {
- if (ID)
- /* enable VBUS valid, IDDIG groung */
- __raw_writel(AVALID | VBUSVALID, ctrl_base +
- USBOTGHS_CONTROL);
- else
- /*
-* Enable VBUS Valid, AValid and IDDIG
-* high impedance
-*/
- __raw_writel(IDDIG | AVALID | VBUSVALID,
- ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable session END and IDIG to high impedance. */
- __raw_writel(SESSEND | IDDIG, ctrl_base +
- USBOTGHS_CONTROL);
- }
- return 0;
-}
-
-int omap4430_phy_suspend(struct device *dev, int suspend)
-{
- if (suspend) {
- /* Disable the clocks */
- omap4430_phy_set_clk(dev, 0);
- /* Power down the phy */
- __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF);
-
- /* save the context */
- usbotghs_control = __raw_readl(ctrl_base + USBOTGHS_CONTROL);
- } else {
- /* Enable the internel phy clcoks */
- omap4430_phy_set_clk(dev, 1);
- /* power on the phy */
- if (__raw_readl(ctrl_base + CONTROL_DEV_CONF) PHY_PD) {
- __raw_writel(~PHY_PD, ctrl_base + CONTROL_DEV_CONF);
- mdelay(200);
- }
-
- /* restore the context */
- __raw_writel(usbotghs_control, ctrl_base + USBOTGHS_CONTROL);
- }
-
- return 0;
-}
-
-int omap4430_phy_exit(struct device *dev)
-{
- if (ctrl_base)
-
[PATCH v1 09/11] drivers: usb: musb: Add device tree support for omap musb glue
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/usb/omap-usb.txt | 34 -
drivers/usb/musb/omap2430.c| 52
2 files changed, 85 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt
b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 80a28c9..39cdffb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -1,4 +1,4 @@
-OMAP USB PHY
+OMAP USB PHY AND GLUE
OMAP USB2 PHY
@@ -14,3 +14,35 @@ usb2phy@0x4a0ad080 {
compatible = ti,omap-usb2;
reg = 0x4a0ad080 0x58;
};
+
+OMAP MUSB GLUE
+ - compatible : Should be ti,musb-omap2430
+ - ti,hwmods : must be usb_otg_hs
+ - multipoint : Should be 1 indicating the musb controller supports
+ multipoint. This is a MUSB configuration-specific setting.
+ - num_eps : Specifies the number of endpoints. This is also a
+ MUSB configuration-specific setting. Should be set to 16
+ - ram_bits : Specifies the ram address size. Should be set to 12
+ - interface_type : This is a board specific setting to describe the type of
+ interface between the controller and the phy. It should be 0 or 1
+ specifying ULPI and UTMI respectively.
+ - mode : Should be 3 to represent OTG. 1 signifies HOST and 2
+ represents PERIPHERAL.
+ - power : Should be 50. This signifies the controller can supply upto
+ 100mA when operating in host mode.
+
+SOC specific device node entry
+usb_otg_hs: usb_otg_hs@4a0ab000 {
+ compatible = ti,musb-omap2430;
+ ti,hwmods = usb_otg_hs;
+ multipoint = 1;
+ num_eps = 16;
+ ram_bits = 12;
+};
+
+Board specific device node entry
+usb_otg_hs {
+ interface_type = 1;
+ mode = 3;
+ power = 50;
+};
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index a50bd73..c750f11 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -30,6 +30,7 @@
#include linux/init.h
#include linux/list.h
#include linux/io.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/pm_runtime.h
@@ -469,8 +470,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -500,6 +504,43 @@ static int __devinit omap2430_probe(struct platform_device
*pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
+ ret = -ENOMEM;
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
@@ -597,12 +638,23 @@ static struct dev_pm_ops omap2430_pm_ops = {
#define DEV_PM_OPS NULL
#endif
+#ifdef CONFIG_OF
+static const struct of_device_id omap2430_id_table[] = {
+ {
[PATCH v1 05/11] drivers: usb: twl6030: Add dt support for twl6030 usb
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 18
drivers/usb/otg/twl6030-usb.c | 45 ++--
2 files changed, 50 insertions(+), 13 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/twl-usb.txt
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
new file mode 100644
index 000..f293271
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -0,0 +1,18 @@
+USB COMPARATOR OF TWL CHIPS
+
+TWL6030 USB COMPARATOR
+ - compatible : Should be ti,twl6030-usb
+ - interrupts : Two interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts when
+ the controller has to act as host and the second interrupt number is the
+ usb interrupt number that raises VBUS interrupts when the controller has to
+ act as device
+ - regulator : supply-name can be vusb or ldousb
+ - supply-name-supply : phandle to the regulator device tree node
+
+twl6030-usb {
+ compatible = ti,twl6030-usb;
+ interrupts = 4 10 ;
+ regulator = vusb;
+ vusb-supply = vusb;
+};
diff --git a/drivers/usb/otg/twl6030-usb.c b/drivers/usb/otg/twl6030-usb.c
index 6a361d2..20b7abe 100644
--- a/drivers/usb/otg/twl6030-usb.c
+++ b/drivers/usb/otg/twl6030-usb.c
@@ -105,7 +105,7 @@ struct twl6030_usb {
u8 asleep;
boolirq_enabled;
boolvbus_enable;
- unsigned long features;
+ const char *regulator;
};
#definecomparator_to_twl(x) container_of((x), struct twl6030_usb,
comparator)
@@ -153,13 +153,6 @@ static int twl6030_start_srp(struct phy_companion
*comparator)
static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
{
- char *regulator_name;
-
- if (twl-features TWL6025_SUBCLASS)
- regulator_name = ldousb;
- else
- regulator_name = vusb;
-
/* Set to OTG_REV 1.3 and turn on the ID_WAKEUP_COMP */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x1, TWL6030_BACKUP_REG);
@@ -169,7 +162,7 @@ static int twl6030_usb_ldo_init(struct twl6030_usb *twl)
/* Program MISC2 register and set bit VUSB_IN_VBAT */
twl6030_writeb(twl, TWL6030_MODULE_ID0 , 0x10, TWL6030_MISC2);
- twl-usb3v3 = regulator_get(twl-dev, regulator_name);
+ twl-usb3v3 = regulator_get(twl-dev, twl-regulator);
if (IS_ERR(twl-usb3v3))
return -ENODEV;
@@ -324,9 +317,9 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
{
struct twl6030_usb *twl;
int status, err;
- struct twl4030_usb_data *pdata;
- struct device *dev = pdev-dev;
- pdata = dev-platform_data;
+ struct device_node *np = pdev-dev.of_node;
+ struct device *dev = pdev-dev;
+ struct twl4030_usb_data *pdata = dev-platform_data;
twl = devm_kzalloc(dev, sizeof *twl, GFP_KERNEL);
if (!twl)
@@ -335,13 +328,28 @@ static int __devinit twl6030_usb_probe(struct
platform_device *pdev)
twl-dev= pdev-dev;
twl-irq1 = platform_get_irq(pdev, 0);
twl-irq2 = platform_get_irq(pdev, 1);
- twl-features = pdata-features;
twl-linkstat = OMAP_MUSB_UNKNOWN;
twl-comparator.set_vbus= twl6030_set_vbus;
twl-comparator.start_srp = twl6030_start_srp;
omap_usb2_set_comparator(twl-comparator);
+ if (np) {
+ err = of_property_read_string(np, regulator, twl-regulator);
+ if (err 0) {
+ dev_err(pdev-dev, unable to get regulator\n);
+ return err;
+ }
+ } else if (pdata) {
+ if (pdata-features TWL6025_SUBCLASS)
+ twl-regulator = ldousb;
+ else
+ twl-regulator = vusb;
+ } else {
+ dev_err(pdev-dev, twl6030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
/* init spinlock for workqueue */
spin_lock_init(twl-lock);
@@ -403,12 +411,23 @@ static int __exit twl6030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl6030_usb_id_table[] = {
+ { .compatible = ti,twl6030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl6030_usb_id_table);
+#else
+#define twl6030_usb_id_table NULL
+#endif
+
static struct platform_driver twl6030_usb_driver = {
.probe = twl6030_usb_probe,
.remove = __exit_p(twl6030_usb_remove),
[PATCH v1 07/11] drivers: usb: twl4030: Add device tree support for twl4030 usb
Add device tree support for twl6030 usb driver.
Update the Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
.../devicetree/bindings/usb/twl-usb.txt| 19 +
drivers/usb/otg/twl4030-usb.c | 28 +++
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/twl-usb.txt
b/Documentation/devicetree/bindings/usb/twl-usb.txt
index f293271..2d069e4 100644
--- a/Documentation/devicetree/bindings/usb/twl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twl-usb.txt
@@ -16,3 +16,22 @@ twl6030-usb {
regulator = vusb;
vusb-supply = vusb;
};
+
+TWL4030 USB PHY AND COMPARATOR
+ - compatible : Should be ti,twl4030-usb
+ - interrupts : The interrupt numbers to the cpu should be specified. First
+ interrupt number is the otg interrupt number that raises ID interrupts
+ and VBUS interrupts. The second interrupt number is optional.
+ - supply-name-supply : phandle to the regulator device tree node.
+ supply-name should be vusb1v5, vusb1v8 and vusb3v1
+ - usb_mode : The mode used by the phy to connect to the controller. 1
+ specifies ULPI mode and 2 specifies CEA2011_3PIN mode.
+
+twl4030-usb {
+ compatible = ti,twl4030-usb;
+ interrupts = 10 4 ;
+ vusb1v5-supply = vusb1v5;
+ vusb1v8-supply = vusb1v8;
+ vusb3v1-supply = vusb3v1;
+ usb_mode = 1;
+};
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index 523cad5..a4e7434 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -585,23 +585,28 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
struct twl4030_usb *twl;
int status, err;
struct usb_otg *otg;
-
- if (!pdata) {
- dev_dbg(pdev-dev, platform_data not available\n);
- return -EINVAL;
- }
+ struct device_node *np = pdev-dev.of_node;
twl = devm_kzalloc(pdev-dev, sizeof *twl, GFP_KERNEL);
if (!twl)
return -ENOMEM;
+ if (np)
+ of_property_read_u32(np, usb_mode,
+ (enum twl4030_usb_mode *)twl-usb_mode);
+ else if (pdata)
+ twl-usb_mode = pdata-usb_mode;
+ else {
+ dev_err(pdev-dev, twl4030 initialized without pdata\n);
+ return -EINVAL;
+ }
+
otg = devm_kzalloc(pdev-dev, sizeof *otg, GFP_KERNEL);
if (!otg)
return -ENOMEM;
twl-dev= pdev-dev;
twl-irq= platform_get_irq(pdev, 0);
- twl-usb_mode = pdata-usb_mode;
twl-vbus_supplied = false;
twl-asleep = 1;
twl-linkstat = OMAP_MUSB_UNKNOWN;
@@ -690,12 +695,23 @@ static int __exit twl4030_usb_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id twl4030_usb_id_table[] = {
+ { .compatible = ti,twl4030-usb },
+ {}
+};
+MODULE_DEVICE_TABLE(of, twl4030_usb_id_table);
+#else
+#define twl4030_usb_id_table NULL
+#endif
+
static struct platform_driver twl4030_usb_driver = {
.probe = twl4030_usb_probe,
.remove = __exit_p(twl4030_usb_remove),
.driver = {
.name = twl4030_usb,
.owner = THIS_MODULE,
+ .of_match_table = twl4030_usb_id_table,
},
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1 03/11] drivers: usb: otg: make twl6030_usb as a comparator driver to omap_usb2
All the PHY configuration other than VBUS, ID GND and OTG SRP are removed
from twl6030. The phy configurations are taken care by the dedicated
usb2 phy driver. So twl6030 is made as comparator driver for VBUS and
ID detection.
Writing to control module which is now handled in omap2430.c should be
removed once a driver for control module is in place.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/omap2430.c | 52 ---
drivers/usb/musb/omap2430.h |9 +++
drivers/usb/otg/twl6030-usb.c | 114 +
3 files changed, 67 insertions(+), 108 deletions(-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2813490..a50bd73 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -44,6 +44,7 @@ struct omap2430_glue {
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
+ u32 __iomem *control_otghs;
};
#define glue_to_musb(g)platform_get_drvdata(g-musb)
@@ -51,6 +52,26 @@ struct omap2430_glue *_glue;
static struct timer_list musb_idle_timer;
+/**
+ * omap4_usb_phy_mailbox - write to usb otg mailbox
+ * @glue: struct omap2430_glue *
+ * @val: the value to be written to the mailbox
+ *
+ * On detection of a device (ID pin is grounded), this API should be called
+ * to set AVALID, VBUSVALID and ID pin is grounded.
+ *
+ * When OMAP is connected to a host (OMAP in device mode), this API
+ * is called to set AVALID, VBUSVALID and ID pin in high impedance.
+ *
+ * XXX: This function will be removed once we have a seperate driver for
+ * control module
+ */
+static void omap4_usb_phy_mailbox(struct omap2430_glue *glue, u32 val)
+{
+ if (glue-control_otghs)
+ writel(val, glue-control_otghs);
+}
+
static void musb_do_idle(unsigned long _musb)
{
struct musb *musb = (void *)_musb;
@@ -245,6 +266,7 @@ EXPORT_SYMBOL_GPL(omap_musb_mailbox);
static void omap_musb_set_mailbox(struct omap2430_glue *glue)
{
+ u32 val;
struct musb *musb = glue_to_musb(glue);
struct device *dev = musb-controller;
struct musb_hdrc_platform_data *pdata = dev-platform_data;
@@ -260,7 +282,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_ID;
if (!is_otg_enabled(musb) || musb-gadget_driver) {
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
omap2430_musb_set_vbus(musb, 1);
}
break;
@@ -273,7 +296,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
musb-xceiv-last_event = USB_EVENT_VBUS;
if (musb-gadget_driver)
pm_runtime_get_sync(dev);
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
case OMAP_MUSB_ID_FLOAT:
@@ -291,7 +315,8 @@ static void omap_musb_set_mailbox(struct omap2430_glue
*glue)
if (musb-xceiv-otg-set_vbus)
otg_set_vbus(musb-xceiv-otg, 0);
}
- usb_phy_shutdown(musb-xceiv);
+ val = SESSEND | IDDIG;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
dev_dbg(dev, ID float\n);
@@ -366,6 +391,7 @@ err1:
static void omap2430_musb_enable(struct musb *musb)
{
u8 devctl;
+ u32 val;
unsigned long timeout = jiffies + msecs_to_jiffies(1000);
struct device *dev = musb-controller;
struct omap2430_glue *glue = dev_get_drvdata(dev-parent);
@@ -375,7 +401,8 @@ static void omap2430_musb_enable(struct musb *musb)
switch (glue-status) {
case OMAP_MUSB_ID_GROUND:
- usb_phy_init(musb-xceiv);
+ val = AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
if (data-interface_type != MUSB_INTERFACE_UTMI)
break;
devctl = musb_readb(musb-mregs, MUSB_DEVCTL);
@@ -394,7 +421,8 @@ static void omap2430_musb_enable(struct musb *musb)
break;
case OMAP_MUSB_VBUS_VALID:
- usb_phy_init(musb-xceiv);
+ val = IDDIG | AVALID | VBUSVALID;
+ omap4_usb_phy_mailbox(glue, val);
break;
default:
@@ -404,11 +432,14 @@ static void omap2430_musb_enable(struct musb *musb)
static void omap2430_musb_disable(struct musb *musb)
{
+ u32 val;
struct device *dev = musb-controller;
struct omap2430_glue *glue =
Re: [PATCH 2/4] ARM: OMAP2+: Move the stubbed prm and cm functions to prcm.c file and make them __weak.
Ping.. Thanks, Sricharan On Thu, Jun 14, 2012 at 5:26 PM, R, Sricharan r.sricha...@ti.com wrote: Hi Paul, Some prm and cm registers read/write and status functions are built only for some custom OMAP2+ builds and are stubbed in header files for other builds under ifdef statements. But this results in adding new CONFIG_ARCH_OMAPXXX checks when SOCs are added in the future. So move them to a common place for OMAP2+ and make them 'weak' implementations. Thanks for the patch. These stubs aren't needed any longer, so we can just get rid of them; no need to mark them __weak. I've got a patch to just drop them here to be posted soon as part of a larger PRCM cleanup. Is the PRCM cleanup series available now ? Thanks, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On 06/28/12 19:10, the mail apparently from Tomi Valkeinen included:
On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
On 28 June 2012 16:17, Jassi Brar jaswinder.si...@linaro.org wrote:
On 28 June 2012 15:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct hdmi_ip_data
*ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
There's a problem with this patch, which leaves a wrong EDID in the
cache: if you first have the cable connected and hdmi is enabled, you
then turn off the HDMI display device via sysfs, we do not go to
hdmi_check_hpd_state at all. The next time hdmi is enabled, we only get
the plug-in event, and thus EDID cache is never invalidated.
If the hdmi cable is not replugged during that period, I don't see why
would you want the EDID invalidated ?
I wasn't very clear with my comment.
When the display device is disabled, we're not listening to the hpd
interrupt anymore. So when it's disabled, the cable can be replugged and
the monitor changed, and the driver won't know about it. And so it'll
return the old EDID for the new monitor.
If that could be a problem, then we already have some problem with
current omapdss.
I think among the first things, while enabling HDMI, should be to see
if there is really some display connected on the port i.e, HPD
asserted. Only if ti_hdmi_4_detect() returned true, should we
proceed otherwise wait for HPQ irq.
Unconditionally invalidating edid really seems like a regression - we
impose atleast 50ms (edid read) as extra cost on
hdmi_check_hpd_state(), which kills half the purpose of this patch.
Sorry a correction. Reading detect() won't work. I suggest we keep HPD
IRQ enabled for the lifetime of the driver.
Ok, I see. But that's not acceptable. It would require us to keep the
TPD12S015 always powered and enabled. Even if you're not interested in
using HDMI at all.
For this to work like you want we need a bigger restructuring of HDMI
and partly omapdss also. Currently we have just one big enabled or
disabled state. We need multiple states. Probably something like:
- disabled, everything totally off
- low power, hotplug detection enabled
- powered on, but no video
- video enabled
Been long in my mind, but I'm not very familiar with HDMI so I could get
my simple prototypes to work when I tried something like this once.
That doesn't sound too hard since the difference between the first three
states at the HDMI chip is just whether the two gpio controlling it are
00, 10 or 11.
If Jassi's alright with it we might have a go at implementing this, but
can you define a bit more about how we logically tell DSS that we want
to, eg, disable HDMI totally?
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs | Follow Linaro
http://facebook.com/pages/Linaro/155974581091106 -
http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP AM35xx: some fixes for 3.6 (fwd)
Hi, * Paul Walmsley p...@pwsan.com [120628 01:25]: The following changes since commit 6b16351acbd415e66ba16bf7d473ece1574cf0bc: Linux 3.5-rc4 (2012-06-24 12:53:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git for you to fetch changes up to a77e1c4d09c88f98ac2e653382d2c1861dbb736f: Merge branches 'am35xx_hwmod_data_fixes_a_3.6', 'am35xx_emac_mdio_devel_3.6' and 'am35xx_prcm_data_devel_3.6' into am35xx_devel_3.6 (2012-06-28 00:13:19 -0600) Some OMAP AM35xx fixes. The powerdomain and clockdomain data for the AM35xx are finally fixed. The AM35xx EMAC/MDIO Ethernet controller integration code has been converted to use the OMAP device and hwmod framework. Also the UART4 and HSOTGUSB warnings have been fixed. Looks like the tag name or git branch to pull is missing above? There's just the git tree. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On 06/28/12 19:38, the mail apparently from Tomi Valkeinen included: On Thu, 2012-06-28 at 14:10 +0300, Tomi Valkeinen wrote: On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote: Sorry a correction. Reading detect() won't work. I suggest we keep HPD IRQ enabled for the lifetime of the driver. Ok, I see. But that's not acceptable. It would require us to keep the TPD12S015 always powered and enabled. Even if you're not interested in using HDMI at all. Btw, a bigger problem that I see is how we have to do read_edid() (and detect(), if I recall correctly): we enable the whole video pipeline and output. We should only enable enough of the HW to be able to read the EDID or read the HPD GPIO. I've noticed that this leads to sync losts quite easily, as we switch the hdmi output on and off quickly multiple times. I couldn't figure out why the sync losts happen though, and I did try quite many different combinations how to handle it. SYNC LOST is one evil lurking in there, the other evil is EDID fetch operation stopped error. We were unable to figure out what was trampling on what there without the SoC HDMI PHY IP data which we don't have. Also at the moment I think we depower / repower the internal SoC and external PHY chip more than we need. Each time we remove the HDMI link power, after a short time where the big capacitor at the charge pump output decays enough (a time dependent on exact details of load presented by the TV or monitor...), hpd from the monitor goes low and remains there until we power the charge pump again. In turn the new hpd recognition provokes a new edid fetch. Something about that sequence provokes the operation stopped on EDID fetch, with Jassi's patches we manage to avoid it. Removing that syndrome, and just not enabling and disabling stuff like SoC HDMI PHY willy nilly can maybe be something else targeted by this proposed 4-state power scheme. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On 28 June 2012 16:40, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote: Sorry a correction. Reading detect() won't work. I suggest we keep HPD IRQ enabled for the lifetime of the driver. Ok, I see. But that's not acceptable. It would require us to keep the TPD12S015 always powered and enabled. Even if you're not interested in using HDMI at all. I think we need to differentiate between HDMI PHY enable and HDMI 5V+,HPD enable [1]... currently they are clubbed together in omap_dss_device.platform_enable. AFAIK, at least with TPD12S015, they can be controlled independently and PHY enabling is actually the main source of power consumption if no display is connected. By 'lifetime' I mean when the end-user selects some option to the effect of Automatically detect and configure display over HDMI and then we simply enable the HDMI 5V+/HPD, HDMI-PHY would be enabled only when we actually detect HPD asserted. If a device doesn't have a port or the user doesn't have a display, neither would be ever enabled. I mean we should provide a way to make it platform dependent. [1] Thanks to Andy and his crappy TV, he found clubbing enabling PHY with 5V+ application comes in the way of detecting cheapo displays that take ~700ms before asserting HPD i.e, making EDID available. See how we don't leave it to a HDMI display to take it's own time before asserting HPD - omapdss_hdmi_display_enable/disable pairs don't care for that. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
* Mohammed, Afzal af...@ti.com [120628 02:36]: Hi Tony, On Wed, Jun 27, 2012 at 20:28:45, Tony Lindgren wrote: The last patch in this series causes onenand not to show up on my n900. I believe the problem has been there earlier too, but I just did not notice it. Sorry for the delayed response, could reach workplace a short while ago only Could the diff [1] be tried and check whether it resolves the issue, Regards Afzal [1] diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. Relieved, thanks Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v5 3/3] ARM: OMAP2+: onenand: prepare for gpmc driver migration
Hi Tony, On Thu, Jun 28, 2012 at 18:02:07, Tony Lindgren wrote: * Mohammed, Afzal af...@ti.com [120628 02:36]: diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c index c8a9487..bbae674 100644 --- a/arch/arm/mach-omap2/gpmc-onenand.c +++ b/arch/arm/mach-omap2/gpmc-onenand.c @@ -364,6 +364,8 @@ static int omap2_onenand_setup_async(void __iomem *onenand_base) struct gpmc_timings t; int ret; + omap2_onenand_set_async_mode(onenand_base); + t = omap2_onenand_calc_async_timings(); ret = gpmc_set_async_mode(gpmc_onenand_data-cs, t); Yes that seems to do the trick, thanks! I can fold that into the breaking patch when applying. Also following needs to be removed from commit message, Ensuring sync read/write are disabled in onenand cannot be expected to work properly unless GPMC is setup, this has been removed. With the above diff we are in effect disabling sync mode in onenand before GPMC has been setup in the Kernel If you want, I can sent a new series too. Regards Afzal -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On 28 June 2012 17:33, Andy Green andy.gr...@linaro.org wrote:
On 06/28/12 19:10, the mail apparently from Tomi Valkeinen included:
On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote:
On 28 June 2012 16:17, Jassi Brar jaswinder.si...@linaro.org wrote:
On 28 June 2012 15:44, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Thu, 2012-06-28 at 15:18 +0530, Jassi Brar wrote:
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -243,10 +243,13 @@ static int hdmi_check_hpd_state(struct
hdmi_ip_data *ip_data)
hpd = gpio_get_value(ip_data-hpd_gpio);
- if (hpd)
+ if (hpd) {
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_TXON);
- else
+ } else {
+ /* Invalidate EDID Cache */
+ ip_data-edid_len = 0;
r = hdmi_set_phy_pwr(ip_data, HDMI_PHYPWRCMD_LDOON);
+ }
There's a problem with this patch, which leaves a wrong EDID in the
cache: if you first have the cable connected and hdmi is enabled, you
then turn off the HDMI display device via sysfs, we do not go to
hdmi_check_hpd_state at all. The next time hdmi is enabled, we only
get
the plug-in event, and thus EDID cache is never invalidated.
If the hdmi cable is not replugged during that period, I don't see why
would you want the EDID invalidated ?
I wasn't very clear with my comment.
When the display device is disabled, we're not listening to the hpd
interrupt anymore. So when it's disabled, the cable can be replugged
and
the monitor changed, and the driver won't know about it. And so it'll
return the old EDID for the new monitor.
If that could be a problem, then we already have some problem with
current omapdss.
I think among the first things, while enabling HDMI, should be to see
if there is really some display connected on the port i.e, HPD
asserted. Only if ti_hdmi_4_detect() returned true, should we
proceed otherwise wait for HPQ irq.
Unconditionally invalidating edid really seems like a regression - we
impose atleast 50ms (edid read) as extra cost on
hdmi_check_hpd_state(), which kills half the purpose of this patch.
Sorry a correction. Reading detect() won't work. I suggest we keep HPD
IRQ enabled for the lifetime of the driver.
Ok, I see. But that's not acceptable. It would require us to keep the
TPD12S015 always powered and enabled. Even if you're not interested in
using HDMI at all.
For this to work like you want we need a bigger restructuring of HDMI
and partly omapdss also. Currently we have just one big enabled or
disabled state. We need multiple states. Probably something like:
- disabled, everything totally off
- low power, hotplug detection enabled
- powered on, but no video
- video enabled
Been long in my mind, but I'm not very familiar with HDMI so I could get
my simple prototypes to work when I tried something like this once.
That doesn't sound too hard since the difference between the first three
states at the HDMI chip is just whether the two gpio controlling it are 00,
10 or 11.
If Jassi's alright with it we might have a go at implementing this, but can
you define a bit more about how we logically tell DSS that we want to, eg,
disable HDMI totally?
A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during
probe and disable during remove.
HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only
HDMI_PHY on/off.
The user selecting Autodetect and Configure option would then equate
to (un)loading of the HDMI driver.
Not to mean a trivial job.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On Thu, 2012-06-28 at 18:43 +0530, Jassi Brar wrote: On 28 June 2012 17:33, Andy Green andy.gr...@linaro.org wrote: If Jassi's alright with it we might have a go at implementing this, but can you define a bit more about how we logically tell DSS that we want to, eg, disable HDMI totally? A quick reaction of my guts say, we simply enable 5V/HPD_IRQ during probe and disable during remove. The problem with this is a feature of omapdss: we can have multiple displays for the same output, of which only one can be enabled at the same time. What this means is that you shouldn't (and in some cases can't) allocate or enable resources in probe that may be shared, because then the driver for both displays would try to allocate the same resource. Sure, this is not a problem for the HDMI configuration we are using now, but it's still against the panel model we have. Thus we should allocate resources only when the panel device is turned on, and release them when it's disabled. I do think the model is slightly broken, but that's what we have now. And I'm also not even sure how it should be fixed... And also, as I said earlier, if you keep it enabled all the time, it'll eat power even if the user is never going to use HDMI. On a desktop I guess the power consumption wouldn't be an issue, but I do feel a bit uneasy about it on an embedded device. HDMI enable/disable via /sysfs/ and HPD (de)assertion, switch only HDMI_PHY on/off. The user selecting Autodetect and Configure option would then equate to (un)loading of the HDMI driver. HDMI cannot be currently compiled as a separate module. Although I think you can detach a device and a driver, achieving the same. Is that what you meant with unloading? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH 3/3] OMAPDSS: HDMI: Cache EDID
On Thu, 2012-06-28 at 16:28 +0530, Jassi Brar wrote: I think among the first things, while enabling HDMI, should be to see if there is really some display connected on the port i.e, HPD asserted. Only if ti_hdmi_4_detect() returned true, should we proceed otherwise wait for HPQ irq. Unconditionally invalidating edid really seems like a regression - we impose atleast 50ms (edid read) as extra cost on hdmi_check_hpd_state(), which kills half the purpose of this patch. Sorry a correction. Reading detect() won't work. I suggest we keep HPD IRQ enabled for the lifetime of the driver. By the way, when the device is in system suspend, we surely won't detect the HPD even if we kept the HPD always enabled. So there we'll miss the HPD interrupt anyway, and the EDID cache would be invalid. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v3 0/7] OMAP System Control Module
Hello again, On Thu, Jun 28, 2012 at 9:29 AM, Valentin, Eduardo eduardo.valen...@ti.com wrote: Hello Konstantin, On Thu, Jun 28, 2012 at 7:43 AM, Eduardo Valentin eduardo.valen...@ti.com wrote: Hello, On Wed, Jun 27, 2012 at 10:04:32PM +0400, Konstantin Baydarov wrote: Hello. This is a next version of series of patches(based on Eduardo Valentin's patch set) adding a basic support for system control module, on OMAP4+ context. It is a working in progress. Main changes since previous patch set version: - Bandgap and usb phy: drivers are now independent from control module driver, they use their own functions to acess scm registers. Well, I believe the idea of having them with their own io resource was to avoid children drivers accessing each other io areas. Is this now working? - omap-control-core: resources aren't hardcoded, they are specified in dts file. - omap-control-core: Control module is a built-in driver - added control module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4. Probably, no configuration option is required! Why is this? I suppose the idea is to have the arch config selecting that flag. - omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows access of SCM registers very early, for example from omap_type() Is this going to be reserved as well? if yes, how children are going to have their own access functions? - omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control module device. - omap-control-core: removed omap_control_get, omap_control_readl, omap_control_writel fine, assuming the io split works... - omap-control-core: added omap_control_status_read that is used early in omap_type - Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers. - Bandgap: Check the type of bandgap dynamically in bandgap driver probe function by reading omap core control module revision register CONTROL_GEN_CORE_REVISION. this has some issue... I will post comment on the patch - Bandgap and usb phy: Parent SCM platform device IOMEM resources is used to get the base address of SCM window. Ohh.. Then what is the point of having them using their own io access functions, nothing is again protected as you have only 1 io resource which is shared. And now is even worse because you have several io access function.. I think this is moving backwards. - Bandgap masks defines were moved to drivers/thermal/omap-bandgap.c. TODO list for bandgap driver: - Reserve omap-control-core IOMEM window. - Improve thermal zone definition for OMAP4 - Introduce the thermal zones for OMAP5 Based on the review comments on RFC patch series, there are more things to be done. I have the O4 and O5 zone definition ready. But that work depends on generic CPU cooling patches. I have also looked the driver support for 4430. But the probing and io resource split is still based on previous design. I have also a patch which does the remapping in the bandgap driver. But really, for this to work it would require to have several entries in the reg property. And that is going to change from BG version to BG version. I can prepare some patches for this. You can find the updated patches here: g...@gitorious.org:thermal-framework/thermal-framework.git thermal_work/omap/bandgap_clean But, as I said they are based on the generic cpu cooling. And the zone registration follows the API as in linux-next. FYI, I just updated the branches on that repo. The branch thermal_work/omap/pu has all required changes in order to get BG driver working on 4430/4460/4470 and O5. It relies on Rui's patch set sent to linux-pm, which reorgs the thermal fw a bit, combined with the generic cpu cooling device by Amit. I also pushed in the 'pu' branch the APIs changes mentioned by Durga on other thread. While checking the pu branch you should be able to get a thermal zone with cpu cooling for OMAP on the mentioned omap versions. Once there is an agreement about the APIs between SCM core driver and its children, I can send out the BG driver patches and this initial omap thermal support using the generic thermal layer. There are some changes in the core thermal layer in the thermal_work/eduardo_thermal_upgrade. But there could be probably some extra changes in the core layer to finalize the omap thermal support. That's a work in progress :-) -- Eduardo Valentin -- Eduardo Valentin -- 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: Bringing back gptimer_wakeup
Kevin Hilman khil...@ti.com writes: Tasslehoff Kjappfot tasskj...@gmail.com writes: The support for using a timer to wake from suspend was removed in: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98e182a26bbbf5575457622337684ef61493e864 I found an alternative patch (http://www.mail-archive.com/linux-omap@vger.kernel.org/msg47836.html) that claimed to keep it working using GPTIMER1 instead, but I haven't been able to make it work (likely because the timer code has changed a good deal since the patch was posted). Anyone got a) a patch that enables this feature on newer kernels, or b) an idea how the patch above can be made to work? The branch below (based on v3.4) will work (at least on OMAP3) We've been holding off on putting this back becasue the timer interface has been going through some major cleanup/rework, but I would like to see this make it back in soonish. Note that another feature that can be used for this same feature is wakeup using RTC. On OMAP3 platoforms with TWL4030 PMIC (which contains an RTC), this is successfully working using the 'rtcwake' utility. E.g., to suspend-to-RAM and trigger an RTC wakeup 4 seconds later, do: # rtcwake -m mem -s 4 The RTC timekeeping seems a bit broken and the actual delay seems to be about 2x the value passed in here, but otherwise this works. There are currently some problems with the OMAP4 RTC driver that prevent this from working, but they need to be investigated. 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: [RFC PATCH 0/2] OMAP2+: PANDA: Provide unique-ish MAC addresses for Ethernet and WLAN interfaces
On Thursday 24 March 2011, Andy Green wrote: The following series solves a problem Panda suffers from where because there is no local MAC address storage on the board, a new random MAC address is applied to the onboard Ethernet interface each time, and the wl12xx module's wlan0 interface is always found with an unworkable 00:00:00:00:00:00 MAC. The series adds an omap id-related API to generate a 6-byte Ethernet MAC address from hashing a little the CPU ID registers. It is understood from TI that these contain data that at least in a subset of the 128 bits of the ID are unique per-CPU. It then introduces code in the Panda board definition file to watch network interface creation and if the device's path is on a list, set its MAC address to the CPU ID-generated one, plus two bits which differ according to which interface in the list is being changed. (This scheme was suggested by Alan Cox). The device paths for the onboard Ethernet smsc95xx, and the onboard WLAN wl12xx are listed, so both of these will get assigned a consistent, unique-ish locally administered MAC address with these patches. It's beleived the current scheme for MAC generation from ID data captures most of the entropy, but if there is a better scheme more closely mapped to what the unique factory areas are advice is welcome. The patches are against linux-omap which already has a prerequisite patch that fixes a problem with device ID capture on OMAP4. It's been a while since we discussed these patches, but Steven Rostedt just tripped over the same problem and the patches work for him, so he says Tested-by: Steven Rostedt rost...@goodmis.org. Can we get the patches into linux-3.6 please? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FYI: Merge issue with linux-omap/master (due to merge 'omap-cleanup-for-v3.5')
Hi Tony, Looks like we have an issue with the merge from branch omap-cleanup-for-v3.5, Patch (ARM: OMAP2+: am33xx: Make am33xx as a separate class) changes AM335X_CLASS to value 0x33500033 and then later merge commit (Merge tag 'omap-cleanup-for-v3.5' into tmp-merge) reverts it back to 0x33500034. Due to this Kernel doesn't boot on BeagleBone platform, below change is required to boot it. --- a/arch/arm/plat-omap/include/plat/cpu.h +++ b/arch/arm/plat-omap/include/plat/cpu.h @@ -396,7 +394,7 @@ IS_OMAP_TYPE(3430, 0x3430) #define AM35XX_REV_ES1_0 AM35XX_CLASS #define AM35XX_REV_ES1_1 (AM35XX_CLASS | (0x1 8)) -#define AM335X_CLASS 0x33500034 +#define AM335X_CLASS 0x33500033 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
[PATCH 00/12] OMAPDSS: Apply LCD manager related parameters
The LCD interface drivers(DPI, DSI, RFBI, SDI) do some direct DISPC register writes to configure LCD manager related fields. This series groups these fields into a single struct, and let's the interface driver apply these parameters. This allows us to: - Check the LCD manager related parameters before applying them. - Remove some omap_dss_device references as APPLY holds the applied parameters. Pushed onto the branch: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git apply_lcd_mgr_params Tested on 3430SDP, 4430SDP ans Pandaboard ES. Archit Taneja (12): OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div() OMAPDSS: Add struct to hold LCD overlay manager configuration OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parameters OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parameters OMAPDSS: DSI: Configure dss_lcd_mgr_config struct with lcd manager parameters OMAPDSS: SDI: Configure dss_lcd_mgr_config struct with lcd manager parameters OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drivers OMAPDSS: MANAGER: Check LCD related overlay manager parameters OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checks OMAPDSS: DISPC: Remove a redundant function OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay manager OMAPDSS: OVERLAY: Clean up replication checking drivers/video/omap2/dss/apply.c | 82 ++-- drivers/video/omap2/dss/dispc.c | 31 --- drivers/video/omap2/dss/display.c | 34 drivers/video/omap2/dss/dpi.c | 31 ++- drivers/video/omap2/dss/dsi.c | 108 ++--- drivers/video/omap2/dss/dss.h | 30 +-- drivers/video/omap2/dss/manager.c | 35 drivers/video/omap2/dss/overlay.c | 13 + drivers/video/omap2/dss/rfbi.c| 39 ++ drivers/video/omap2/dss/sdi.c | 32 +-- 10 files changed, 286 insertions(+), 149 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] MAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div()
dipsc_mgr_set_clock div has an int return type to report errors or success.
The function doesn't really check for errors and always returns 0. Change
the return type to void.
Checking for the correct DISPC clock divider ranges will be done when a DSS2
user does a manager apply. This support will be added later.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |4 +---
drivers/video/omap2/dss/dpi.c | 10 ++
drivers/video/omap2/dss/dsi.c |6 +-
drivers/video/omap2/dss/dss.h |2 +-
drivers/video/omap2/dss/sdi.c |5 +
5 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 864adcc..b047fe6 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3184,15 +3184,13 @@ int dispc_calc_clock_rates(unsigned long
dispc_fclk_rate,
return 0;
}
-int dispc_mgr_set_clock_div(enum omap_channel channel,
+void dispc_mgr_set_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo)
{
DSSDBG(lck = %lu (%u)\n, cinfo-lck, cinfo-lck_div);
DSSDBG(pck = %lu (%u)\n, cinfo-pck, cinfo-pck_div);
dispc_mgr_set_lcd_divisor(channel, cinfo-lck_div, cinfo-pck_div);
-
- return 0;
}
int dispc_mgr_get_clock_div(enum omap_channel channel,
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 046a6fb..af01430 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -100,11 +100,7 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
dss_select_dispc_clk_source(clks-dispc.fclk_src);
- r = dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
- if (r) {
- dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
- return r;
- }
+ dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
*fck = dsi_cinfo.dsi_pll_hsdiv_dispc_clk;
*lck_div = dispc_cinfo.lck_div;
@@ -129,9 +125,7 @@ static int dpi_set_dispc_clk(struct omap_dss_device *dssdev,
if (r)
return r;
- r = dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
- if (r)
- return r;
+ dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
*fck = dss_cinfo.fck;
*lck_div = dispc_cinfo.lck_div;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 9f08787..94ff3aa 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4456,11 +4456,7 @@ static int dsi_configure_dispc_clocks(struct
omap_dss_device *dssdev,
return r;
}
- r = dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
- if (r) {
- DSSERR(Failed to set dispc clocks\n);
- return r;
- }
+ dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
return 0;
}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 20151d5..f8289e9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -416,7 +416,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
unsigned long dispc_mgr_pclk_rate(enum omap_channel channel);
unsigned long dispc_core_clk_rate(void);
-int dispc_mgr_set_clock_div(enum omap_channel channel,
+void dispc_mgr_set_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo);
int dispc_mgr_get_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo);
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index b44ab72..0b2659f 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -106,9 +106,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_set_dss_clock_div;
- r = dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
- if (r)
- goto err_set_dispc_clock_div;
+ dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
dss_sdi_init(dssdev-phy.sdi.datapairs);
r = dss_sdi_enable();
@@ -125,7 +123,6 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
err_mgr_enable:
dss_sdi_disable();
err_sdi_enable:
-err_set_dispc_clock_div:
err_set_dss_clock_div:
err_calc_clock_div:
dispc_runtime_put();
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] OMAPDSS: DISPC: Change return type of dispc_mgr_set_clock_div()
dipsc_mgr_set_clock div has an int return type to report errors or success.
The function doesn't really check for errors and always returns 0. Change
the return type to void.
Checking for the correct DISPC clock divider ranges will be done when a DSS2
user does a manager apply. This support will be added later.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c |4 +---
drivers/video/omap2/dss/dpi.c | 10 ++
drivers/video/omap2/dss/dsi.c |6 +-
drivers/video/omap2/dss/dss.h |2 +-
drivers/video/omap2/dss/sdi.c |5 +
5 files changed, 6 insertions(+), 21 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 864adcc..b047fe6 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3184,15 +3184,13 @@ int dispc_calc_clock_rates(unsigned long
dispc_fclk_rate,
return 0;
}
-int dispc_mgr_set_clock_div(enum omap_channel channel,
+void dispc_mgr_set_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo)
{
DSSDBG(lck = %lu (%u)\n, cinfo-lck, cinfo-lck_div);
DSSDBG(pck = %lu (%u)\n, cinfo-pck, cinfo-pck_div);
dispc_mgr_set_lcd_divisor(channel, cinfo-lck_div, cinfo-pck_div);
-
- return 0;
}
int dispc_mgr_get_clock_div(enum omap_channel channel,
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 046a6fb..af01430 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -100,11 +100,7 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
dss_select_dispc_clk_source(clks-dispc.fclk_src);
- r = dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
- if (r) {
- dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
- return r;
- }
+ dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
*fck = dsi_cinfo.dsi_pll_hsdiv_dispc_clk;
*lck_div = dispc_cinfo.lck_div;
@@ -129,9 +125,7 @@ static int dpi_set_dispc_clk(struct omap_dss_device *dssdev,
if (r)
return r;
- r = dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
- if (r)
- return r;
+ dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
*fck = dss_cinfo.fck;
*lck_div = dispc_cinfo.lck_div;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 9f08787..94ff3aa 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4456,11 +4456,7 @@ static int dsi_configure_dispc_clocks(struct
omap_dss_device *dssdev,
return r;
}
- r = dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
- if (r) {
- DSSERR(Failed to set dispc clocks\n);
- return r;
- }
+ dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
return 0;
}
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 20151d5..f8289e9 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -416,7 +416,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
unsigned long dispc_mgr_lclk_rate(enum omap_channel channel);
unsigned long dispc_mgr_pclk_rate(enum omap_channel channel);
unsigned long dispc_core_clk_rate(void);
-int dispc_mgr_set_clock_div(enum omap_channel channel,
+void dispc_mgr_set_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo);
int dispc_mgr_get_clock_div(enum omap_channel channel,
struct dispc_clock_info *cinfo);
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index b44ab72..0b2659f 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -106,9 +106,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_set_dss_clock_div;
- r = dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
- if (r)
- goto err_set_dispc_clock_div;
+ dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
dss_sdi_init(dssdev-phy.sdi.datapairs);
r = dss_sdi_enable();
@@ -125,7 +123,6 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
err_mgr_enable:
dss_sdi_disable();
err_sdi_enable:
-err_set_dispc_clock_div:
err_set_dss_clock_div:
err_calc_clock_div:
dispc_runtime_put();
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/12] OMAPDSS: Add struct to hold LCD overlay manager configuration
Create a struct dss_lcd_mgr_config which holds LCD overlay manager related
parameters. These are currently partially contained in the omap_dss_device
connected to the manager, and the rest are in the interface driver.
The parameters are directly written to the DISPC registers in the interface
drivers. These should eventually be applied at the correct time using the
shadow register programming model. This struct would help in grouping these
parameters so that they can be applied together.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dss.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f8289e9..6688eaf 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -152,6 +152,19 @@ struct dsi_clock_info {
u16 lp_clk_div;
};
+struct dss_lcd_mgr_config {
+ enum dss_io_pad_mode io_pad_mode;
+
+ bool stallmode;
+ bool fifohandcheck;
+
+ struct dispc_clock_info clock_info;
+
+ int video_port_width;
+
+ int lcden_sig_polarity;
+};
+
struct seq_file;
struct platform_device;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/12] OMAPDSS: DPI: Configure dss_lcd_mgr_config struct with lcd manager parameters
Create a dss_lcd_mgr_config struct instance in DPI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by DPI.
Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.
The DISPC_DIVISORo registers were written in the functions dpi_set_dispc_clk()
and dpi_set_dsi_clk(), now they just fill up the dispc_clock_info parameter in
mgr_config. They are written later in dpi_config_lcd_manager.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dpi.c | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index af01430..a3a012b 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -38,6 +38,8 @@
static struct {
struct regulator *vdds_dsi_reg;
struct platform_device *dsidev;
+
+ struct dss_lcd_mgr_config mgr_config;
} dpi;
static struct platform_device *dpi_get_dsidev(enum omap_dss_clk_source clk)
@@ -100,7 +102,7 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
dss_select_dispc_clk_source(clks-dispc.fclk_src);
- dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
+ dpi.mgr_config.clock_info = dispc_cinfo;
*fck = dsi_cinfo.dsi_pll_hsdiv_dispc_clk;
*lck_div = dispc_cinfo.lck_div;
@@ -125,7 +127,7 @@ static int dpi_set_dispc_clk(struct omap_dss_device *dssdev,
if (r)
return r;
- dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
+ dpi.mgr_config.clock_info = dispc_cinfo;
*fck = dss_cinfo.fck;
*lck_div = dispc_cinfo.lck_div;
@@ -166,15 +168,32 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
return 0;
}
-static void dpi_basic_init(struct omap_dss_device *dssdev)
+static void dpi_config_lcd_manager(struct omap_dss_device *dssdev)
{
- dispc_mgr_set_io_pad_mode(DSS_IO_PAD_MODE_BYPASS);
- dispc_mgr_enable_stallmode(dssdev-manager-id, false);
+ dpi.mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
- dispc_mgr_set_lcd_type_tft(dssdev-manager-id);
+ dpi.mgr_config.stallmode = false;
+ dpi.mgr_config.fifohandcheck = false;
+
+ dpi.mgr_config.video_port_width = dssdev-phy.dpi.data_lines;
+
+ dpi.mgr_config.lcden_sig_polarity = false;
+
+ dispc_mgr_set_io_pad_mode(dpi.mgr_config.io_pad_mode);
+ dispc_mgr_enable_stallmode(dssdev-manager-id,
+ dpi.mgr_config.stallmode);
+ dispc_mgr_enable_fifohandcheck(dssdev-manager-id,
+ dpi.mgr_config.fifohandcheck);
dispc_mgr_set_tft_data_lines(dssdev-manager-id,
- dssdev-phy.dpi.data_lines);
+ dpi.mgr_config.video_port_width);
+
+ dispc_mgr_set_clock_div(dssdev-manager-id,
+ dpi.mgr_config.clock_info);
+
+ dispc_lcd_enable_signal_polarity(dpi.mgr_config.lcden_sig_polarity);
+
+ dispc_mgr_set_lcd_type_tft(dssdev-manager-id);
}
int omapdss_dpi_display_enable(struct omap_dss_device *dssdev)
@@ -213,8 +232,6 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_get_dispc;
- dpi_basic_init(dssdev);
-
if (dpi_use_dsi_pll(dssdev)) {
r = dsi_runtime_get(dpi.dsidev);
if (r)
@@ -229,6 +246,8 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_set_mode;
+ dpi_config_lcd_manager(dssdev);
+
mdelay(2);
r = dss_mgr_enable(dssdev-manager);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] OMAPDSS: RFBI: Configure dss_lcd_mgr_config struct with lcd manager parameters
Create a dss_lcd_mgr_config struct instance in RFBI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by RFBI.
Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.
Create function rfbi_config_lcd_manager() which fills up the mgr_config
parameters and writes to the DISPC regs.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 45084d8..847f694 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -859,6 +859,33 @@ static void rfbi_dump_regs(struct seq_file *s)
#undef DUMPREG
}
+static void rfbi_config_lcd_manager(struct omap_dss_device *dssdev)
+{
+ struct dss_lcd_mgr_config mgr_config;
+
+ mgr_config.io_pad_mode = DSS_IO_PAD_MODE_RFBI;
+
+ mgr_config.stallmode = true;
+ /* Do we need fifohandcheck for RFBI? */
+ mgr_config.fifohandcheck = false;
+
+ mgr_config.video_port_width = dssdev-ctrl.pixel_size;
+ mgr_config.lcden_sig_polarity = 0;
+
+ dispc_mgr_set_io_pad_mode(mgr_config.io_pad_mode);
+
+ dispc_mgr_enable_stallmode(dssdev-manager-id, mgr_config.stallmode);
+ dispc_mgr_enable_fifohandcheck(dssdev-manager-id,
+ mgr_config.fifohandcheck);
+
+ dispc_mgr_set_tft_data_lines(dssdev-manager-id,
+ mgr_config.video_port_width);
+
+ dispc_lcd_enable_signal_polarity(mgr_config.lcden_sig_polarity);
+
+ dispc_mgr_set_lcd_type_tft(dssdev-manager-id);
+}
+
int omapdss_rfbi_display_enable(struct omap_dss_device *dssdev)
{
int r;
@@ -885,12 +912,7 @@ int omapdss_rfbi_display_enable(struct omap_dss_device
*dssdev)
goto err1;
}
- dispc_mgr_set_lcd_type_tft(dssdev-manager-id);
-
- dispc_mgr_set_io_pad_mode(DSS_IO_PAD_MODE_RFBI);
- dispc_mgr_enable_stallmode(dssdev-manager-id, true);
-
- dispc_mgr_set_tft_data_lines(dssdev-manager-id,
dssdev-ctrl.pixel_size);
+ rfbi_config_lcd_manager(dssdev);
rfbi_configure(dssdev-phy.rfbi.channel,
dssdev-ctrl.pixel_size,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/12] OMAPDSS: DSI: Configure dss_lcd_mgr_config struct with lcd manager parameters
Create a dss_lcd_mgr_config struct instance in DSI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by DSI.
Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.
The function dsi_configure_dispc_clocks() is now called in
dsi_display_init_dispc(), this lets all the lcd manager related configurations
happen in the same place. The DISPC_DIVISORo register was written in
dsi_configure_dispc_clock(), now it just fills up the dispc_clock_info parameter
in mgr_config. The clock_info is written later in dsi_display_init_dispc().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 117 -
1 file changed, 80 insertions(+), 37 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 94ff3aa..df92e24 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -331,6 +331,8 @@ struct dsi_data {
unsigned num_lanes_used;
unsigned scp_clk_refcount;
+
+ struct dss_lcd_mgr_config mgr_config;
};
struct dsi_packet_sent_handler_data {
@@ -4339,14 +4341,42 @@ EXPORT_SYMBOL(omap_dsi_update);
/* Display funcs */
-static int dsi_display_init_dispc(struct omap_dss_device *dssdev)
+static int dsi_configure_dispc_clocks(struct omap_dss_device *dssdev,
+ const struct omapdss_lcd_clock_config *lcd_clks)
{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ struct dispc_clock_info dispc_cinfo;
int r;
+ unsigned long long fck;
+
+ fck = dsi_get_pll_hsdiv_dispc_rate(dsidev);
+
+ dispc_cinfo.lck_div = lcd_clks-lck_div;
+ dispc_cinfo.pck_div = lcd_clks-pck_div;
+
+ r = dispc_calc_clock_rates(fck, dispc_cinfo);
+ if (r) {
+ DSSERR(Failed to calc dispc clocks\n);
+ return r;
+ }
+
+ dsi-mgr_config.clock_info = dispc_cinfo;
+
+ return 0;
+}
+
+static int dsi_display_init_dispc(struct omap_dss_device *dssdev)
+{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
struct omap_video_timings timings;
+ const struct omapdss_clock_config *clks;
+ int r, lcd_id;
+ u32 irq;
if (dssdev-panel.dsi_mode == OMAP_DSS_DSI_CMD_MODE) {
u16 dw, dh;
- u32 irq;
dssdev-driver-get_resolution(dssdev, dw, dh);
@@ -4366,16 +4396,16 @@ static int dsi_display_init_dispc(struct
omap_dss_device *dssdev)
(void *) dssdev, irq);
if (r) {
DSSERR(can't get FRAMEDONE irq\n);
- return r;
+ goto err;
}
- dispc_mgr_enable_stallmode(dssdev-manager-id, true);
- dispc_mgr_enable_fifohandcheck(dssdev-manager-id, 1);
+ dsi-mgr_config.stallmode = true;
+ dsi-mgr_config.fifohandcheck = true;
} else {
timings = dssdev-panel.timings;
- dispc_mgr_enable_stallmode(dssdev-manager-id, false);
- dispc_mgr_enable_fifohandcheck(dssdev-manager-id, 0);
+ dsi-mgr_config.stallmode = false;
+ dsi-mgr_config.fifohandcheck = false;
}
/*
@@ -4391,12 +4421,53 @@ static int dsi_display_init_dispc(struct
omap_dss_device *dssdev)
dss_mgr_set_timings(dssdev-manager, timings);
- dispc_mgr_set_lcd_type_tft(dssdev-manager-id);
+ clks = dss_get_platform_clock_config();
+
+ switch (dssdev-manager-id) {
+ case OMAP_DSS_CHANNEL_LCD:
+ lcd_id = 0;
+ break;
+ case OMAP_DSS_CHANNEL_LCD2:
+ lcd_id = 1;
+ break;
+ default:
+ r = -EINVAL;
+ goto err1;
+ }
+
+ r = dsi_configure_dispc_clocks(dssdev, clks-lcd[lcd_id]);
+ if (r)
+ goto err1;
+
+ dsi-mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
+ dsi-mgr_config.video_port_width =
+ dsi_get_pixel_size(dssdev-panel.dsi_pix_fmt);
+ dsi-mgr_config.lcden_sig_polarity = 0;
+
+ dispc_mgr_set_io_pad_mode(dsi-mgr_config.io_pad_mode);
+
+ dispc_mgr_enable_stallmode(dssdev-manager-id,
+ dsi-mgr_config.stallmode);
+ dispc_mgr_enable_fifohandcheck(dssdev-manager-id,
+ dsi-mgr_config.fifohandcheck);
+
+ dispc_mgr_set_clock_div(dssdev-manager-id,
+ dsi-mgr_config.clock_info);
dispc_mgr_set_tft_data_lines(dssdev-manager-id,
- dsi_get_pixel_size(dssdev-panel.dsi_pix_fmt));
+
[PATCH 06/12] OMAPDSS: SDI: Configure dss_lcd_mgr_config struct with lcd manager parameters
Create a dss_lcd_mgr_config struct instance in SDI. Fill up all the parameters
of the struct with configurations held by the panel, and the configurations
required by SDI.
Use these to write to the DISPC registers. These direct register writes would be
later replaced by a function which applies the configuration using the shadow
register programming model.
Create function sdi_config_lcd_manager() which fills the mgr_config parameters
and writes to the DISPC registers
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/sdi.c | 42 +
1 file changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 0b2659f..f6cd96c 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -32,18 +32,34 @@
static struct {
bool update_enabled;
struct regulator *vdds_sdi_reg;
-} sdi;
-static void sdi_basic_init(struct omap_dss_device *dssdev)
+ struct dss_lcd_mgr_config mgr_config;
+} sdi;
+static void sdi_config_lcd_manager(struct omap_dss_device *dssdev)
{
- dispc_mgr_set_io_pad_mode(DSS_IO_PAD_MODE_BYPASS);
- dispc_mgr_enable_stallmode(dssdev-manager-id, false);
+ sdi.mgr_config.io_pad_mode = DSS_IO_PAD_MODE_BYPASS;
- dispc_mgr_set_lcd_type_tft(dssdev-manager-id);
+ sdi.mgr_config.stallmode = false;
+ sdi.mgr_config.fifohandcheck = false;
+
+ sdi.mgr_config.video_port_width = 24;
+ sdi.mgr_config.lcden_sig_polarity = 1;
+
+ dispc_mgr_set_io_pad_mode(sdi.mgr_config.io_pad_mode);
+ dispc_mgr_enable_stallmode(dssdev-manager-id,
+ sdi.mgr_config.stallmode);
+ dispc_mgr_enable_fifohandcheck(dssdev-manager-id,
+ sdi.mgr_config.fifohandcheck);
- dispc_mgr_set_tft_data_lines(dssdev-manager-id, 24);
- dispc_lcd_enable_signal_polarity(1);
+ dispc_mgr_set_clock_div(dssdev-manager-id,
+ sdi.mgr_config.clock_info);
+
+ dispc_mgr_set_tft_data_lines(dssdev-manager-id,
+ sdi.mgr_config.video_port_width);
+ dispc_lcd_enable_signal_polarity(sdi.mgr_config.lcden_sig_polarity);
+
+ dispc_mgr_set_lcd_type_tft(dssdev-manager-id);
}
int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
@@ -51,8 +67,6 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
struct omap_video_timings *t = dssdev-panel.timings;
struct dss_clock_info dss_cinfo;
struct dispc_clock_info dispc_cinfo;
- u16 lck_div, pck_div;
- unsigned long fck;
unsigned long pck;
int r;
@@ -75,8 +89,6 @@ int omapdss_sdi_display_enable(struct omap_dss_device *dssdev)
if (r)
goto err_get_dispc;
- sdi_basic_init(dssdev);
-
/* 15.5.9.1.2 */
dssdev-panel.timings.pclk_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
dssdev-panel.timings.hsync_vsync_edge = OMAPDSS_DRIVE_SIG_RISING_EDGE;
@@ -85,11 +97,9 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_calc_clock_div;
- fck = dss_cinfo.fck;
- lck_div = dispc_cinfo.lck_div;
- pck_div = dispc_cinfo.pck_div;
+ sdi.mgr_config.clock_info = dispc_cinfo;
- pck = fck / lck_div / pck_div / 1000;
+ pck = dss_cinfo.fck / dispc_cinfo.lck_div / dispc_cinfo.pck_div / 1000;
if (pck != t-pixel_clock) {
DSSWARN(Could not find exact pixel clock. Requested %d kHz,
@@ -106,7 +116,7 @@ int omapdss_sdi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_set_dss_clock_div;
- dispc_mgr_set_clock_div(dssdev-manager-id, dispc_cinfo);
+ sdi_config_lcd_manager(dssdev);
dss_sdi_init(dssdev-phy.sdi.datapairs);
r = dss_sdi_enable();
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/12] OMAPDSS: APPLY: Remove DISPC writes to manager's lcd parameters in interface drivers
Replace the DISPC fuctions used to configure LCD channel related manager
parameters with dss_mgr_set_lcd_config() in APPLY. This function ensures that
the DISPC registers are written at the right time by using the shadow register
programming model.
The LCD manager configurations is stored as a private data of manager in APPLY.
It is treated as an extra info as it's the panel drivers which trigger this
apply via interface drivers, and not a DSS2 user like omapfb or omapdrm.
Storing LCD manager related properties in APPLY also prevents the need to refer
to the panel connected to the manager for information. This helps in making the
DSS driver less dependent on panel.
A helper function is added to check whether the manager is LCD or TV. The direct
DISPC register writes are removed from the interface drivers.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c | 65 +++
drivers/video/omap2/dss/dpi.c | 16 +-
drivers/video/omap2/dss/dsi.c | 17 +-
drivers/video/omap2/dss/dss.h | 10 ++
drivers/video/omap2/dss/rfbi.c | 13 +---
drivers/video/omap2/dss/sdi.c | 15 +
6 files changed, 79 insertions(+), 57 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 3ce7a3e..bb4ec63 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -104,6 +104,7 @@ struct mgr_priv_data {
bool shadow_extra_info_dirty;
struct omap_video_timings timings;
+ struct dss_lcd_mgr_config lcd_config;
};
static struct {
@@ -137,6 +138,7 @@ static struct mgr_priv_data *get_mgr_priv(struct
omap_overlay_manager *mgr)
void dss_apply_init(void)
{
const int num_ovls = dss_feat_get_num_ovls();
+ struct mgr_priv_data *mp;
int i;
spin_lock_init(data_lock);
@@ -168,6 +170,16 @@ void dss_apply_init(void)
op-user_info = op-info;
}
+
+ /*
+* Initialize some of the lcd_config fields for TV manager, this lets
+* us prevent checking if the manager is LCD or TV at some places
+*/
+ mp = dss_data.mgr_priv_data_array[OMAP_DSS_CHANNEL_DIGIT];
+
+ mp-lcd_config.video_port_width = 24;
+ mp-lcd_config.clock_info.lck_div = 1;
+ mp-lcd_config.clock_info.pck_div = 1;
}
static bool ovl_manual_update(struct omap_overlay *ovl)
@@ -633,6 +645,24 @@ static void dss_mgr_write_regs_extra(struct
omap_overlay_manager *mgr)
dispc_mgr_set_timings(mgr-id, mp-timings);
+ /* lcd_config parameters */
+ if (dss_mgr_is_lcd(mgr-id)) {
+ dispc_mgr_set_io_pad_mode(mp-lcd_config.io_pad_mode);
+
+ dispc_mgr_enable_stallmode(mgr-id, mp-lcd_config.stallmode);
+ dispc_mgr_enable_fifohandcheck(mgr-id,
+ mp-lcd_config.fifohandcheck);
+
+ dispc_mgr_set_clock_div(mgr-id, mp-lcd_config.clock_info);
+
+ dispc_mgr_set_tft_data_lines(mgr-id,
+ mp-lcd_config.video_port_width);
+
+
dispc_lcd_enable_signal_polarity(mp-lcd_config.lcden_sig_polarity);
+
+ dispc_mgr_set_lcd_type_tft(mgr-id);
+ }
+
mp-extra_info_dirty = false;
if (mp-updating)
mp-shadow_extra_info_dirty = true;
@@ -1292,6 +1322,41 @@ void dss_mgr_set_timings(struct omap_overlay_manager
*mgr,
mutex_unlock(apply_lock);
}
+static void dss_apply_mgr_lcd_config(struct omap_overlay_manager *mgr,
+ struct dss_lcd_mgr_config config)
+{
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ mp-lcd_config = config;
+ mp-extra_info_dirty = true;
+}
+
+void dss_mgr_set_lcd_config(struct omap_overlay_manager *mgr,
+ struct dss_lcd_mgr_config config)
+{
+ unsigned long flags;
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ mutex_lock(apply_lock);
+
+ if (mp-enabled)
+ goto out;
+
+ spin_lock_irqsave(data_lock, flags);
+
+ dss_apply_mgr_lcd_config(mgr, config);
+
+ dss_write_regs();
+ dss_set_go_bits();
+
+ spin_unlock_irqrestore(data_lock, flags);
+
+ wait_pending_extra_info_updates();
+
+out:
+ mutex_unlock(apply_lock);
+}
+
int dss_ovl_set_info(struct omap_overlay *ovl,
struct omap_overlay_info *info)
{
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index a3a012b..c10c0f8 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -179,21 +179,7 @@ static void dpi_config_lcd_manager(struct omap_dss_device
*dssdev)
dpi.mgr_config.lcden_sig_polarity = false;
- dispc_mgr_set_io_pad_mode(dpi.mgr_config.io_pad_mode);
- dispc_mgr_enable_stallmode(dssdev-manager-id,
- dpi.mgr_config.stallmode);
- dispc_mgr_enable_fifohandcheck(dssdev-manager-id,
-
[PATCH 08/12] OMAPDSS: MANAGER: Check LCD related overlay manager parameters
The LCD related manager configurations are a part of the manager's private data
in APPLY. Pass this to dss_lcd_mgr_config to dss_mgr_check and create a function
to check the validity of some of the configurations.
To check some of the configurations, we require information of interface to
which the manager output is connected. These can be added once interfaces are
represented as an entity.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c |2 +-
drivers/video/omap2/dss/dss.h |1 +
drivers/video/omap2/dss/manager.c | 35 +++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index bb4ec63..95a6713 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -226,7 +226,7 @@ static int dss_check_settings_low(struct
omap_overlay_manager *mgr,
ois[ovl-id] = oi;
}
- return dss_mgr_check(mgr, mi, mp-timings, ois);
+ return dss_mgr_check(mgr, mi, mp-timings, mp-lcd_config, ois);
}
/*
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index b4c52ec..cb859e3 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -235,6 +235,7 @@ int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_overlay_manager_info *info,
const struct omap_video_timings *mgr_timings,
+ const struct dss_lcd_mgr_config *config,
struct omap_overlay_info **overlay_infos);
static inline bool dss_mgr_is_lcd(enum omap_channel id)
diff --git a/drivers/video/omap2/dss/manager.c
b/drivers/video/omap2/dss/manager.c
index 0cbcde4..09540bc 100644
--- a/drivers/video/omap2/dss/manager.c
+++ b/drivers/video/omap2/dss/manager.c
@@ -665,9 +665,40 @@ int dss_mgr_check_timings(struct omap_overlay_manager *mgr,
return 0;
}
+static int dss_mgr_check_lcd_config(struct omap_overlay_manager *mgr,
+ const struct dss_lcd_mgr_config *config)
+{
+ struct dispc_clock_info cinfo = config-clock_info;
+ int dl = config-video_port_width;
+ bool stallmode = config-stallmode;
+ bool fifohandcheck = config-fifohandcheck;
+
+ if (cinfo.lck_div 1 || cinfo.lck_div 255)
+ return -EINVAL;
+
+ if (cinfo.pck_div 1 || cinfo.pck_div 255)
+ return -EINVAL;
+
+ if (dl != 12 dl != 16 dl != 18 dl != 24)
+ return -EINVAL;
+
+ /* fifohandcheck should be used only with stallmode */
+ if (stallmode == false fifohandcheck == true)
+ return -EINVAL;
+
+ /*
+* io pad mode can be only checked by using dssdev connected to the
+* manager. Ignore checking these for now, add checks when manager
+* is capable of holding information related to the connected interface
+*/
+
+ return 0;
+}
+
int dss_mgr_check(struct omap_overlay_manager *mgr,
struct omap_overlay_manager_info *info,
const struct omap_video_timings *mgr_timings,
+ const struct dss_lcd_mgr_config *lcd_config,
struct omap_overlay_info **overlay_infos)
{
struct omap_overlay *ovl;
@@ -683,6 +714,10 @@ int dss_mgr_check(struct omap_overlay_manager *mgr,
if (r)
return r;
+ r = dss_mgr_check_lcd_config(mgr, lcd_config);
+ if (r)
+ return r;
+
list_for_each_entry(ovl, mgr-overlays, list) {
struct omap_overlay_info *oi;
int r;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/12] OMAPDSS: APPLY: Remove usage of omap_dss_device from manual/auto update checks
APPLY needs to know at certain places whether an overlay manager is in manual
or auto update mode. The caps of the connected omap_dss_device were used to
check that.
A LCD manager is in manual update if stallmode is enabled for that manager. TV
managers for now always auto update.
Return the value of stallmode parameter in the private data 'lcd_confg' in
mgr_manual_update() and ovl_manual_update(), for TV managers stallmode field
will be false by default.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 95a6713..b9c6e75 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -182,14 +182,23 @@ void dss_apply_init(void)
mp-lcd_config.clock_info.pck_div = 1;
}
+/*
+ * A LCD manager's stallmode decides whether it is in manual or auto update. TV
+ * manager is always auto update, stallmode field for TV manager is false by
+ * default
+ */
static bool ovl_manual_update(struct omap_overlay *ovl)
{
- return ovl-manager-device-caps OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
+ struct mgr_priv_data *mp = get_mgr_priv(ovl-manager);
+
+ return mp-lcd_config.stallmode;
}
static bool mgr_manual_update(struct omap_overlay_manager *mgr)
{
- return mgr-device-caps OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE;
+ struct mgr_priv_data *mp = get_mgr_priv(mgr);
+
+ return mp-lcd_config.stallmode;
}
static int dss_check_settings_low(struct omap_overlay_manager *mgr,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] OMAPDSS: DISPC: Remove a redundant function
dss_mgr_is_lcd() available in dss.h does the same thing as dispc_mgr_is_lcd()
in dispc.c. Remove the function from dispc.c and replace it with the one in
dss.h.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 27 +--
1 file changed, 9 insertions(+), 18 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index b047fe6..0e0b89c 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -387,15 +387,6 @@ void dispc_runtime_put(void)
WARN_ON(r 0);
}
-static inline bool dispc_mgr_is_lcd(enum omap_channel channel)
-{
- if (channel == OMAP_DSS_CHANNEL_LCD ||
- channel == OMAP_DSS_CHANNEL_LCD2)
- return true;
- else
- return false;
-}
-
u32 dispc_mgr_get_vsync_irq(enum omap_channel channel)
{
switch (channel) {
@@ -430,7 +421,7 @@ bool dispc_mgr_go_busy(enum omap_channel channel)
{
int bit;
- if (dispc_mgr_is_lcd(channel))
+ if (dss_mgr_is_lcd(channel))
bit = 5; /* GOLCD */
else
bit = 6; /* GODIGIT */
@@ -446,7 +437,7 @@ void dispc_mgr_go(enum omap_channel channel)
int bit;
bool enable_bit, go_bit;
- if (dispc_mgr_is_lcd(channel))
+ if (dss_mgr_is_lcd(channel))
bit = 0; /* LCDENABLE */
else
bit = 1; /* DIGITALENABLE */
@@ -460,7 +451,7 @@ void dispc_mgr_go(enum omap_channel channel)
if (!enable_bit)
return;
- if (dispc_mgr_is_lcd(channel))
+ if (dss_mgr_is_lcd(channel))
bit = 5; /* GOLCD */
else
bit = 6; /* GODIGIT */
@@ -939,7 +930,7 @@ static void dispc_mgr_set_cpr_coef(enum omap_channel
channel,
{
u32 coef_r, coef_g, coef_b;
- if (!dispc_mgr_is_lcd(channel))
+ if (!dss_mgr_is_lcd(channel))
return;
coef_r = FLD_VAL(coefs-rr, 31, 22) | FLD_VAL(coefs-rg, 20, 11) |
@@ -1798,7 +1789,7 @@ static int check_horiz_timing_omap3(enum omap_channel
channel,
nonactive = t-x_res + t-hfp + t-hsw + t-hbp - out_width;
pclk = dispc_mgr_pclk_rate(channel);
- if (dispc_mgr_is_lcd(channel))
+ if (dss_mgr_is_lcd(channel))
lclk = dispc_mgr_lclk_rate(channel);
else
lclk = dispc_fclk_rate();
@@ -2398,7 +2389,7 @@ bool dispc_mgr_is_enabled(enum omap_channel channel)
void dispc_mgr_enable(enum omap_channel channel, bool enable)
{
- if (dispc_mgr_is_lcd(channel))
+ if (dss_mgr_is_lcd(channel))
dispc_mgr_enable_lcd_out(channel, enable);
else if (channel == OMAP_DSS_CHANNEL_DIGIT)
dispc_mgr_enable_digit_out(enable);
@@ -2610,7 +2601,7 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
timings_ok = _dispc_mgr_size_ok(timings-x_res, timings-y_res);
- if (dispc_mgr_is_lcd(channel))
+ if (dss_mgr_is_lcd(channel))
timings_ok = timings_ok _dispc_lcd_timings_ok(timings-hsw,
timings-hfp, timings-hbp,
timings-vsw, timings-vfp,
@@ -2702,7 +2693,7 @@ void dispc_mgr_set_timings(enum omap_channel channel,
return;
}
- if (dispc_mgr_is_lcd(channel)) {
+ if (dss_mgr_is_lcd(channel)) {
_dispc_mgr_set_lcd_timings(channel, t.hsw, t.hfp, t.hbp, t.vsw,
t.vfp, t.vbp, t.vsync_level, t.hsync_level,
t.pclk_edge, t.de_level, t.hsync_vsync_edge);
@@ -2808,7 +2799,7 @@ unsigned long dispc_mgr_pclk_rate(enum omap_channel
channel)
{
unsigned long r;
- if (dispc_mgr_is_lcd(channel)) {
+ if (dss_mgr_is_lcd(channel)) {
int pcd;
u32 l;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] OMAPDSS: RFBI: Use dss_mgr_enable to enable the overlay manager
The RFBI driver uses a direct DISPC register write to enable the overlay
manager. Replace this with dss_mgr_enable() which checks if the connected
overlay and managers are correctly configured, and configure DSS for
fifomerge.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 0376056..8c5d5df 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -300,10 +300,11 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int
scr_width,
}
EXPORT_SYMBOL(omap_rfbi_write_pixels);
-static void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
+static int rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
u16 height, void (*callback)(void *data), void *data)
{
u32 l;
+ int r;
struct omap_video_timings timings = {
.hsw= 1,
.hfp= 1,
@@ -322,7 +323,9 @@ static void rfbi_transfer_area(struct omap_dss_device
*dssdev, u16 width,
dss_mgr_set_timings(dssdev-manager, timings);
- dispc_mgr_enable(dssdev-manager-id, true);
+ r = dss_mgr_enable(dssdev-manager);
+ if (r)
+ return r;
rfbi.framedone_callback = callback;
rfbi.framedone_callback_data = data;
@@ -335,6 +338,8 @@ static void rfbi_transfer_area(struct omap_dss_device
*dssdev, u16 width,
l = FLD_MOD(l, 1, 4, 4); /* ITE */
rfbi_write_reg(RFBI_CONTROL, l);
+
+ return 0;
}
static void framedone_callback(void *data, u32 mask)
@@ -814,8 +819,11 @@ int omap_rfbi_update(struct omap_dss_device *dssdev,
u16 x, u16 y, u16 w, u16 h,
void (*callback)(void *), void *data)
{
- rfbi_transfer_area(dssdev, w, h, callback, data);
- return 0;
+ int r;
+
+ r = rfbi_transfer_area(dssdev, w, h, callback, data);
+
+ return r;
}
EXPORT_SYMBOL(omap_rfbi_update);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/12] OMAPDSS: OVERLAY: Clean up replication checking
Replication logic for an overlay depends on the color mode in which it is
configured and the video port width of the manager it is connected to.
video port width now held in dss_lcd_mgr_config in the manager's private
data in APPLY. Use this instead of referring to the omap_dss_device connected to
the manager.
Replication is enabled in the case of TV manager, the video_port_width is set to
a default value of 24 for TV manager.
Make the replication checking an overlay function since it's more of an overlay
characteristic than a display characteristic.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/apply.c |2 +-
drivers/video/omap2/dss/display.c | 34 --
drivers/video/omap2/dss/dss.h |4 ++--
drivers/video/omap2/dss/overlay.c | 13 +
4 files changed, 16 insertions(+), 37 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index b9c6e75..89ee677 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -571,7 +571,7 @@ static void dss_ovl_write_regs(struct omap_overlay *ovl)
mp = get_mgr_priv(ovl-manager);
- replication = dss_use_replication(ovl-manager-device, oi-color_mode);
+ replication = dss_ovl_use_replication(mp-lcd_config, oi-color_mode);
r = dispc_ovl_setup(ovl-id, oi, replication, mp-timings);
if (r) {
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 1d8198e..9433b92 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -316,40 +316,6 @@ void omapdss_default_get_timings(struct omap_dss_device
*dssdev,
}
EXPORT_SYMBOL(omapdss_default_get_timings);
-/* Checks if replication logic should be used. Only use for active matrix,
- * when overlay is in RGB12U or RGB16 mode, and LCD interface is
- * 18bpp or 24bpp */
-bool dss_use_replication(struct omap_dss_device *dssdev,
- enum omap_color_mode mode)
-{
- int bpp;
-
- if (mode != OMAP_DSS_COLOR_RGB12U mode != OMAP_DSS_COLOR_RGB16)
- return false;
-
- switch (dssdev-type) {
- case OMAP_DISPLAY_TYPE_DPI:
- bpp = dssdev-phy.dpi.data_lines;
- break;
- case OMAP_DISPLAY_TYPE_HDMI:
- case OMAP_DISPLAY_TYPE_VENC:
- case OMAP_DISPLAY_TYPE_SDI:
- bpp = 24;
- break;
- case OMAP_DISPLAY_TYPE_DBI:
- bpp = dssdev-ctrl.pixel_size;
- break;
- case OMAP_DISPLAY_TYPE_DSI:
- bpp = dsi_get_pixel_size(dssdev-panel.dsi_pix_fmt);
- break;
- default:
- BUG();
- return false;
- }
-
- return bpp 16;
-}
-
void dss_init_device(struct platform_device *pdev,
struct omap_dss_device *dssdev)
{
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index cb859e3..018b27c 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -222,8 +222,6 @@ void dss_init_device(struct platform_device *pdev,
struct omap_dss_device *dssdev);
void dss_uninit_device(struct platform_device *pdev,
struct omap_dss_device *dssdev);
-bool dss_use_replication(struct omap_dss_device *dssdev,
- enum omap_color_mode mode);
/* manager */
int dss_init_overlay_managers(struct platform_device *pdev);
@@ -255,6 +253,8 @@ int dss_ovl_simple_check(struct omap_overlay *ovl,
const struct omap_overlay_info *info);
int dss_ovl_check(struct omap_overlay *ovl, struct omap_overlay_info *info,
const struct omap_video_timings *mgr_timings);
+bool dss_ovl_use_replication(struct dss_lcd_mgr_config config,
+ enum omap_color_mode mode);
/* DSS */
int dss_init_platform_driver(void) __init;
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index c492bb0..0a129dc 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -677,3 +677,16 @@ int dss_ovl_check(struct omap_overlay *ovl, struct
omap_overlay_info *info,
return 0;
}
+
+/*
+ * Checks if replication logic should be used. Only use when overlay is in
+ * RGB12U or RGB16 mode, and video port width interface is 18bpp or 24bpp
+ */
+bool dss_ovl_use_replication(struct dss_lcd_mgr_config config,
+ enum omap_color_mode mode)
+{
+ if (mode != OMAP_DSS_COLOR_RGB12U mode != OMAP_DSS_COLOR_RGB16)
+ return false;
+
+ return config.video_port_width 16;
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx
On Sat, Apr 28, 2012 at 07:04:38, Paul Walmsley wrote: On Fri, 17 Feb 2012, Vaibhav Hiremath wrote: In case of AM33xx family of devices (like cpsw) have different sysc bit field offsets defined, sysc_type3: | 3 2 | 10 | | STDBYMODE | IDLEMODE | So introduce new sysc_type3 in omap_hwmod common data. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Thanks, queued for 3.5. We missed this patch last time, can you pleas make sure to include it this time. 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: [RFC PATCH 0/2] OMAP2+: PANDA: Provide unique-ish MAC addresses for Ethernet and WLAN interfaces
On Thu, 2012-06-28 at 14:18 +, Arnd Bergmann wrote: It's been a while since we discussed these patches, but Steven Rostedt just tripped over the same problem and the patches work for him, so he says Tested-by: Steven Rostedt rost...@goodmis.org. Can we get the patches into linux-3.6 please? Yes please. Right now I have my ktest.pl setup adding these patches before running tests. I really dislike having to modify a kernel that I'm testing, because I'm not really testing that said kernel, but a modified version of it. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx
On 6/28/2012 8:10 PM, Hiremath, Vaibhav wrote: On Sat, Apr 28, 2012 at 07:04:38, Paul Walmsley wrote: On Fri, 17 Feb 2012, Vaibhav Hiremath wrote: In case of AM33xx family of devices (like cpsw) have different sysc bit field offsets defined, sysc_type3: | 3 2 | 10 | | STDBYMODE | IDLEMODE | So introduce new sysc_type3 in omap_hwmod common data. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Thanks, queued for 3.5. We missed this patch last time, can you pleas make sure to include it this time. Another patch which got missed from your last pull-request is, ARM: OMAP3/4: omap_hwmod:Add rstst_off field to struct omap_hwmod_omap4_prcm Can you please add it to your pull request? 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
[PATCH-V3 0/3] ARM: OMAP2+: Cleanup series in order to remove ARCH_OMAPx dependency
In current implementation, some places we are still using ARCH_OMAPx config option, making it difficult to add new devices; for example, while adding am33xx device support I came across multiple instances where I had to patch the existing code to make it work for am33xx. This patch tries to cleanup existing code for some of the ARCH_OMAP2/3/4 dependency on the code. NOTE: Patch series has been build tested for all possible combination of OMAP2, 3, 4 configurations. History on Patch-series: Changes from V2: - Rebased against latest linux-omap/master - Removed [Patch 4/4], fixed it separately as independent patch. Already in Mainline. - Fixed comments form KevinH, added Makefile rule for sdrc.c Changes from V1: - Fixed comments from Tony - Config option name of SOC_HAS_SDRC changed to SOC_HAS_OMAP2_SDRC - Config option name for SOC_HAS_DPLL_xxx flags to SOC_HAS_OMAP3_DPLL_xxx. Vaibhav Hiremath (3): ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals arch/arm/mach-omap2/Kconfig|8 arch/arm/mach-omap2/Makefile |3 ++- arch/arm/mach-omap2/clock.c| 18 -- arch/arm/mach-omap2/common.c |8 +--- arch/arm/mach-omap2/common.h |5 + arch/arm/mach-omap2/dpll3xxx.c | 14 ++ arch/arm/plat-omap/Makefile|4 +--- 7 files changed, 31 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
[PATCH-V3 2/3] ARM: OMAP2+: CLEANUP: Move omap3 dpll ops to dpll3xxx.c
In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).
The clkops (clkops_omap3_core_dpll_ops clkops_omap3_noncore_dpll_ops)
is used in clock data files, and dependency is already handled by
Makefile rule.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Acked-by: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
NOTE: No code change from last version.
---
arch/arm/mach-omap2/clock.c| 18 --
arch/arm/mach-omap2/dpll3xxx.c | 14 ++
2 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 5c4e665..ea3f565 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -398,24 +398,6 @@ int omap2_clk_set_parent(struct clk *clk, struct clk
*new_parent)
return omap2_clksel_set_parent(clk, new_parent);
}
-/* OMAP3/4 non-CORE DPLL clkops */
-
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-
-const struct clkops clkops_omap3_noncore_dpll_ops = {
- .enable = omap3_noncore_dpll_enable,
- .disable= omap3_noncore_dpll_disable,
- .allow_idle = omap3_dpll_allow_idle,
- .deny_idle = omap3_dpll_deny_idle,
-};
-
-const struct clkops clkops_omap3_core_dpll_ops = {
- .allow_idle = omap3_dpll_allow_idle,
- .deny_idle = omap3_dpll_deny_idle,
-};
-
-#endif
-
/*
* OMAP2+ clock reset and init functions
*/
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index f0f10be..ff6f237 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -628,3 +628,17 @@ unsigned long omap3_clkoutx2_recalc(struct clk *clk)
rate = clk-parent-rate * 2;
return rate;
}
+
+/* OMAP3/4 non-CORE DPLL clkops */
+
+const struct clkops clkops_omap3_noncore_dpll_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .allow_idle = omap3_dpll_allow_idle,
+ .deny_idle = omap3_dpll_deny_idle,
+};
+
+const struct clkops clkops_omap3_core_dpll_ops = {
+ .allow_idle = omap3_dpll_allow_idle,
+ .deny_idle = omap3_dpll_deny_idle,
+};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V3 3/3] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Changes from V1:
- Added Makefile rule to build sdrc.c file for new
option SOC_HAS_OMAP2_SDRC (as per Kevin's comment).
---
arch/arm/mach-omap2/Kconfig |8
arch/arm/mach-omap2/Makefile |3 ++-
arch/arm/mach-omap2/common.c |8 +---
arch/arm/mach-omap2/common.h |5 +
4 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 208b950..82d9d18 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -21,12 +21,16 @@ config ARCH_OMAP2PLUS_TYPICAL
help
Compile a kernel suitable for booting most boards
+config SOC_HAS_OMAP2_SDRC
+ bool OMAP2 SDRAM Controller support
+
config ARCH_OMAP2
bool TI OMAP2
depends on ARCH_OMAP2PLUS
default y
select CPU_V6
select MULTI_IRQ_HANDLER
+ select SOC_HAS_OMAP2_SDRC
config ARCH_OMAP3
bool TI OMAP3
@@ -39,6 +43,7 @@ config ARCH_OMAP3
select PM_OPP if PM
select ARM_CPU_SUSPEND if PM
select MULTI_IRQ_HANDLER
+ select SOC_HAS_OMAP2_SDRC
config ARCH_OMAP4
bool TI OMAP4
@@ -66,16 +71,19 @@ config SOC_OMAP2420
depends on ARCH_OMAP2
default y
select OMAP_DM_TIMER
+ select SOC_HAS_OMAP2_SDRC
config SOC_OMAP2430
bool OMAP2430 support
depends on ARCH_OMAP2
default y
+ select SOC_HAS_OMAP2_SDRC
config SOC_OMAP3430
bool OMAP3430 support
depends on ARCH_OMAP3
default y
+ select SOC_HAS_OMAP2_SDRC
config SOC_TI81XX
bool TI81XX support
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index e5c17d3..3767164 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -6,7 +6,7 @@
obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \
common.o gpio.o dma.o wd_timer.o display.o i2c.o hdq1w.o
-omap-2-3-common= irq.o sdrc.o
+omap-2-3-common= irq.o
hwmod-common = omap_hwmod.o \
omap_hwmod_common_data.o
clock-common = clock.o clock_common_data.o \
@@ -23,6 +23,7 @@ obj-y += mcbsp.o
endif
obj-$(CONFIG_TWL4030_CORE) += omap_twl.o
+obj-$(CONFIG_SOC_HAS_OMAP2_SDRC) += sdrc.o
# SMP support ONLY available for OMAP4
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 8a6953a..7978e5e 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -29,8 +29,6 @@
/* Global address base setup code */
-#if defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3)
-
static void __init __omap2_set_globals(struct omap_globals *omap2_globals)
{
omap2_set_globals_tap(omap2_globals);
@@ -39,8 +37,6 @@ static void __init __omap2_set_globals(struct omap_globals
*omap2_globals)
omap2_set_globals_prcm(omap2_globals);
}
-#endif
-
#if defined(CONFIG_SOC_OMAP2420)
static struct omap_globals omap242x_globals = {
@@ -171,9 +167,7 @@ static struct omap_globals omap4_globals = {
void __init omap2_set_globals_443x(void)
{
- omap2_set_globals_tap(omap4_globals);
- omap2_set_globals_control(omap4_globals);
- omap2_set_globals_prcm(omap4_globals);
+ __omap2_set_globals(omap4_globals);
}
void __init omap4_map_io(void)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 5d99c1b..404f172 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -174,7 +174,12 @@ void omap2_set_globals_am33xx(void);
/* These get called from omap2_set_globals_(), do not call these */
void omap2_set_globals_tap(struct omap_globals *);
+#if defined(CONFIG_SOC_HAS_OMAP2_SDRC)
void omap2_set_globals_sdrc(struct omap_globals *);
+#else
+static inline void omap2_set_globals_sdrc(struct omap_globals *omap2_globals)
+{ }
+#endif
void omap2_set_globals_control(struct omap_globals *);
void omap2_set_globals_prcm(struct omap_globals *);
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V3 1/3] ARM: OMAP2+: CLEANUP: All OMAP2PLUS uses omap-device.o target so add one entry
All OMAP2PLUS based devices, builds omap-device.o target; so just add one entry so that there is no need to patch this file for any future OMAP2+ devices. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com NOTE: No code change from last version. --- arch/arm/plat-omap/Makefile |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile index 6d87532..961bf85 100644 --- a/arch/arm/plat-omap/Makefile +++ b/arch/arm/plat-omap/Makefile @@ -10,9 +10,7 @@ obj-n := obj- := # omap_device support (OMAP2+ only at the moment) -obj-$(CONFIG_ARCH_OMAP2) += omap_device.o -obj-$(CONFIG_ARCH_OMAP3) += omap_device.o -obj-$(CONFIG_ARCH_OMAP4) += omap_device.o +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_device.o obj-$(CONFIG_OMAP_DM_TIMER) += dmtimer.o obj-$(CONFIG_OMAP_DEBUG_DEVICES) += debug-devices.o -- 1.7.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-V3 3/3] ARM: OMAP2+: CLEANUP: Remove unnecessary ifdef around __omap2_set_globals
Hi Vaibhav, One small comment. On 06/28/2012 04:59 PM, Vaibhav Hiremath wrote: The function __omap2_set_globals() can be common across all platforms/architectures, even in case of omap4, internally it calls same set of functions as in __omap2_set_globals() function (except for sdrc). This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Changes from V1: - Added Makefile rule to build sdrc.c file for new option SOC_HAS_OMAP2_SDRC (as per Kevin's comment). --- arch/arm/mach-omap2/Kconfig |8 arch/arm/mach-omap2/Makefile |3 ++- arch/arm/mach-omap2/common.c |8 +--- arch/arm/mach-omap2/common.h |5 + 4 files changed, 16 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 208b950..82d9d18 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -21,12 +21,16 @@ config ARCH_OMAP2PLUS_TYPICAL help Compile a kernel suitable for booting most boards +config SOC_HAS_OMAP2_SDRC + bool OMAP2 SDRAM Controller support + config ARCH_OMAP2 bool TI OMAP2 depends on ARCH_OMAP2PLUS default y select CPU_V6 select MULTI_IRQ_HANDLER + select SOC_HAS_OMAP2_SDRC config ARCH_OMAP3 bool TI OMAP3 @@ -39,6 +43,7 @@ config ARCH_OMAP3 select PM_OPP if PM select ARM_CPU_SUSPEND if PM select MULTI_IRQ_HANDLER + select SOC_HAS_OMAP2_SDRC config ARCH_OMAP4 bool TI OMAP4 @@ -66,16 +71,19 @@ config SOC_OMAP2420 depends on ARCH_OMAP2 default y select OMAP_DM_TIMER + select SOC_HAS_OMAP2_SDRC OMAP4 does not have the SDRC but the EMIF like TI8XX. Regards, Benoit -- 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: Current state of AM33xx patches
On 27.06.2012 14:13, Hiremath, Vaibhav wrote: Just to clarify from AM335x perspective, In case of AM335x, since the patches and complete BasePort support is still not present in the Mainline (neither in Linus's tree not in linux-omap), you need to use my Repo (https://github.com/hvaibhav: Closely follows linux- omap/master) in order to test something on BeagleBone platform. Great, that is the information I've been looking for. Your am335x-upstream-staging branch works for me on a custom AM335x based board using a custom DT config. I'll dig through the sources and come back once I know which parts are missing. Thanks, Daniel -- 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
[PATCHv11 6/6] i2c: omap: Recover from Bus Busy condition
From: Vikram Pandita vikram.pand...@ti.com
In case a peripheral is driving SDA bus low (ie. a start condition), provide
a constant clock output using the test mode of the OMAP I2C controller to
try and clear the bus. Soft reset I2C controller after attempting the bus clear
to ensure that controller is in a good state.
Based upon Vikram Pandita's patch from TI Android 3.0.
I acknowledge the contributions and suggestions of Jon and Hemant.
A couple differences from the original patch ...
1. Add a new function for bus clear
2. Ensure that the CON.I2C_EN bit is set when using the SYSTEST feature to
output a permanent clock. This bit needs to be set and typically it would
be set by the unidle function but this is not the case for all OMAP
generations.
3. Program the SYSTEST setting only the bits we care about. However, restore
SYSTEST registers to there original state as some OMAP generations do not
implement perform a soft-reset.
4. Clear the CON register after performing the bus clear, so when we call the
init function the controller is disabled and the init function will
re-enable later.
Original patch can be found here:
http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=a2ab04192ba25e60f95ba1ff3af5601a2d7b5bd1
Signed-off-by: Vikram Pandita vikram.pand...@ti.com
Signed-off-by: Jon Hunter jon-hun...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 30 +++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5058dfc..2500f19 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -148,16 +148,15 @@ enum {
#define OMAP_I2C_SCLH_HSSCLH 8
/* I2C System Test Register (OMAP_I2C_SYSTEST): */
-#ifdef DEBUG
#define OMAP_I2C_SYSTEST_ST_EN (1 15) /* System test enable */
#define OMAP_I2C_SYSTEST_FREE (1 14) /* Free running mode */
#define OMAP_I2C_SYSTEST_TMODE_MASK(3 12) /* Test mode select */
-#define OMAP_I2C_SYSTEST_TMODE_SHIFT (12)/* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_TEST(2 12) /* Test mode select */
+#define OMAP_I2C_SYSTEST_TMODE_LOOP(3 12) /* Test mode select */
#define OMAP_I2C_SYSTEST_SCL_I (1 3)/* SCL line sense in */
#define OMAP_I2C_SYSTEST_SCL_O (1 2)/* SCL line drive out */
#define OMAP_I2C_SYSTEST_SDA_I (1 1)/* SDA line sense in */
#define OMAP_I2C_SYSTEST_SDA_O (1 0)/* SDA line drive out */
-#endif
/* OCP_SYSCONFIG bit definitions */
#define SYSC_CLOCKACTIVITY_MASK(0x3 8)
@@ -458,6 +457,29 @@ static int omap_i2c_wait_for_bb(struct omap_i2c_dev *dev)
return 0;
}
+/*
+ * Bus Clear
+ */
+static int omap_i2c_bus_clear(struct omap_i2c_dev *dev)
+{
+ u16 w;
+
+ /*
+* Per the I2C specification, if we are stuck in a bus busy state
+* we can attempt a bus clear to try and recover the bus by sending
+* at least 9 clock pulses on SCL. Put the I2C in a test mode so it
+* will output a continuous clock on SCL.
+*/
+ w = omap_i2c_read_reg(dev, OMAP_I2C_SYSTEST_REG);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, (OMAP_I2C_SYSTEST_ST_EN
+ | OMAP_I2C_SYSTEST_TMODE_TEST));
+ msleep(1);
+ omap_i2c_write_reg(dev, OMAP_I2C_SYSTEST_REG, w);
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ omap_i2c_init(dev);
+ return omap_i2c_wait_for_bb(dev);
+}
/*
* Low level master read/write transaction.
@@ -584,6 +606,8 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
r = omap_i2c_wait_for_bb(dev);
if (r 0)
+ r = omap_i2c_bus_clear(dev);
+ if (r 0)
goto out;
if (dev-set_mpu_wkup_lat != NULL)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv11 0/6] I2C cleanups
This is a minimal cleanup series. The patch series does the following - Bus busy recovery mechanism. - Make the i2c use SET_RUNTIME_PM_OPS - Use INIT_COMPLETION instead of init_completion - the reset patch is dropped will try to rework it as per the review comments recieved. This applies on Wolfram's i2c-embedded/for-next branch. Functional testing on omap4430 , 4460 panda and omap3sdp. The following changes since commit 0f009a914b40be8786fa67b1f4345cacc263b48c: i2c: tegra: make all resource allocation through devm_* (2012-06-13 16:01:38 +0200) are available in the git repository at: git://gitorious.org/linus-tree/linus-tree.git for_next/omap/minimal_cleanup Jon Hunter (1): i2c: omap: Correct I2C revision for OMAP3 Shubhrajyoti D (4): i2c: omap: Optimise the remove code i2c: omap: Use SET_RUNTIME_PM_OPS i2c: omap: Do not initialise the completion everytime i2c: omap: Remove the definition of SYSS_RESETDONE_MASK Vikram Pandita (1): i2c: omap: Recover from Bus Busy condition drivers/i2c/busses/i2c-omap.c | 60 1 files changed, 42 insertions(+), 18 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
