RE: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Paul Walmsley > Sent: Tuesday, March 26, 2013 11:43 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > Tony Lindgren > Subject: Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to > clkdiv32k_ick clock > > On Mon, 25 Mar 2013, Vaibhav Hiremath wrote: > > > During common-clock migration, .clkdm_name field got missed > > for "clkdiv32k_ick" clock, which leaves "clk_24mhz_clkdm" > > unused; so boot process will try to disable the clockdomain > > even childs of this clock is enabled, which keeps child modules > > in idle mode. > > Looks fine to me. You're planning to update the patch description, > right? > So should I wait until you repost it? > Yeup, will submit today. > Also you should probably trim the crash log after "[2.626025] LR is > at > clk_enable+0x30/0x3c" > Ok, Thanks, Vaibhav > > > - 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 -- 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 00/26] DSS device model change
On 2013-03-26 19:10, Tony Lindgren wrote: > * Tomi Valkeinen [130326 06:38]: >> Hi, >> >> To make it possible to add DT support to DSS, and later use the Common >> Display >> Framework, we need to change the DSS device model. We currently have a custom >> dss bus, and omap_dss_devices on that bus, and the aim is to get rid of that >> bus. >> >> The panel devices will be converted occording to the control bus of the >> panel. >> For many panels this means that the panel device will become a >> platform_device. >> For some, it means the panel devices become i2c or spi devices. >> >> This series takes the first step toward that goal. This series: >> >> * Converts DPI, HDMI and DSI outputs to work with new style panels >> * Converts TFP410, Taal and generic-dpi panels to new model >> * Converts Panda, 4430SDP and Overo boards to use the new panels >> >> The non-converted outputs and panels still work, so they can be converted in >> stages. > > This is nice, it removes a merge dependency between ARM code and the driver :) Yes. It does give me a few more gray hairs, though =). It'd be so much easier to have all related changes in one clean patch series. >> Note about board files: I only convert a few board files here for example. I >> have a branch with board file changes for all the affected board files. I did >> not include them as they are more or less identical. If this series looks >> good, >> I will create an independent branch for the arch/arm stuff, so it can be >> pulled >> separately. > > Great looks good to me thanks. To make the DSS work properly after this device model change, we also need to solve the problem related to multiple display devices on the same video bus. Did the approach I suggested in http://permalink.gmane.org/gmane.linux.ports.arm.omap/96039 look ok? Overo is the most complex one, I think the rest of the boards that require changes have just LCD and DVI that conflict. But it still means we'll have that kind of choice Kconfig option for all those boards. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2] ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized
Hi On Thu, 21 Mar 2013, Rajendra Nayak wrote: > clk inits on OMAP happen quite early, even before slab is available. > The dependency comes from the fact that the timer init code starts to > use clocks and hwmod and we need clocks to be initialized by then. > > There are various problems doing clk inits this early, one is, > not being able to do dynamic clk registrations and hence the > dependency on clk-private.h. The other is, inability to debug > early kernel crashes without enabling DEBUG_LL and earlyprintk. ... > Reported-by: Piotr Haber > Reported-by: Tony Lindgren > Signed-off-by: Rajendra Nayak Thanks, looks good to me. Nice patch description! Acked-by: Paul Walmsley - 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: OK to use commit 71856843 as base for further omap clean up?
On Mon, Mar 25, 2013 at 02:31:26PM -0500, Jon Hunter wrote: > Hi Russell, > > On 03/19/2013 12:59 PM, Tony Lindgren wrote: > > Hi Russell, > > > > Can we use your commit 71856843 (ARM: OMAP: use consistent error checking) > > as an immutable base for further omap dmtimer and gpmc work? > > I saw that you updated your clean-up branch. Ok to use the below commit > [1] as a base for some v3.10 updates? It's still the same commit. I'm not intending to remove this commit from it, so yes, fine, go ahead. -- 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 00/26] DSS device model change
* Tomi Valkeinen [130326 06:38]: > Hi, > > To make it possible to add DT support to DSS, and later use the Common Display > Framework, we need to change the DSS device model. We currently have a custom > dss bus, and omap_dss_devices on that bus, and the aim is to get rid of that > bus. > > The panel devices will be converted occording to the control bus of the panel. > For many panels this means that the panel device will become a > platform_device. > For some, it means the panel devices become i2c or spi devices. > > This series takes the first step toward that goal. This series: > > * Converts DPI, HDMI and DSI outputs to work with new style panels > * Converts TFP410, Taal and generic-dpi panels to new model > * Converts Panda, 4430SDP and Overo boards to use the new panels > > The non-converted outputs and panels still work, so they can be converted in > stages. This is nice, it removes a merge dependency between ARM code and the driver :) > Note about board files: I only convert a few board files here for example. I > have a branch with board file changes for all the affected board files. I did > not include them as they are more or less identical. If this series looks > good, > I will create an independent branch for the arch/arm stuff, so it can be > pulled > separately. Great looks good to me thanks. 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: [PATCHv3 02/14] ARM: OMAP2+: mbox: remove dependencies with soc.h
Paul, > > The OMAP mailbox platform driver code has been cleaned up to remove > > the dependencies with soc.h in preparation for moving the mailbox code > > to drivers folder. > > > > The code relied on cpu_is_xxx/soc_is_xxx macros previously to pick the > > the right set of mailbox devices and register with the mailbox driver. > > This data is now represented in a concise format and moved to the > > respective omap_hwmod data files and published to the driver through > > the platform data. > > > > Signed-off-by: Suman Anna > > The hwmod/dev_attr parts look fine to me, but please start thinking about how > to convert the driver to get this data from DT instead. Yes, that is the plan. I will have the DT conversion when I add the support for OMAP5. Regards Suman -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 02/14] ARM: OMAP2+: mbox: remove dependencies with soc.h
Hi, On Tue, 12 Mar 2013, Suman Anna wrote: > The OMAP mailbox platform driver code has been cleaned up to > remove the dependencies with soc.h in preparation for moving > the mailbox code to drivers folder. > > The code relied on cpu_is_xxx/soc_is_xxx macros previously to > pick the the right set of mailbox devices and register with the > mailbox driver. This data is now represented in a concise format > and moved to the respective omap_hwmod data files and published > to the driver through the platform data. > > Signed-off-by: Suman Anna The hwmod/dev_attr parts look fine to me, but please start thinking about how to convert the driver to get this data from DT instead. - 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: OMAP baseline test results for v3.9-rc1
Hi, On Thu, 14 Mar 2013, Hiremath, Vaibhav wrote: > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Paul Walmsley > > Sent: Tuesday, March 12, 2013 10:10 PM > > To: linux-omap@vger.kernel.org > > Cc: linux-arm-ker...@lists.infradead.org > > Subject: OMAP baseline test results for v3.9-rc1 > > > > > > Here are some basic OMAP test results for Linux v3.9-rc1. > > Logs and other details at: > > > > http://www.pwsan.com/omap/testlogs/test_v3.9-rc1/20130312100243/ > > > > > > Test summary > > > > > > Build: > > FAIL ( 4/16): am33xx_only, omap1_defconfig, > This requires some cleanup in Makefile and Kconfig handling, > > Either you disable SMP support for non-SMP devices like AM33xx > > OR > > Fix the Makefile to resolve the build dependencies (may not be trivial) > > OR > > Make functions __weak so that build will go through. > > > > I have created below patch, if it is ok with you then I can > Submit patch for the same (build tested with am33xx_only and > omap2plus_defconfig). Santosh's suggestion seems the right way to go. Care to implement a patch for #2 above? - 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: OMAP baseline test results for v3.9-rc3
Hi. On Tue, 19 Mar 2013, Tero Kristo wrote: > I think you should definitely upgrade your bootloader, the old one you > are using is prone to cause trouble due to bugs it has, and we have no > simple way to workaround the issues it causes on kernel side. So, the kernel should be independent of the bootloader that's used. Many of the rest of us have taken great care to ensure that devices get reset to do this. We've got pretty good coverage on OMAP3 and most of the other OMAP4 IP blocks. You mention that there's no simple way to do it, but as far as I know, no one has assessed what's needed to reset the remaining devices. Or if someone has this information, it hasn't been shared here - please do so. So what I'd like you to do is: 1. Determine what devices are remaining to be reset and idled on OMAP4 with the bootloader that I use. As far as I know, there are only four that block full-chip idle: M3, DSP, SL2IF, FSUSB 2. Determine what's needed to reset and idle them. For the M3 and DSP, I'd assume this involves pointing the reset vector for those processors at a few lines of code that basically enter WFI or the C64x equivalent. 3. At this point, we can determine the difficulty level of the task. 4. Then, assuming it's of the level described in step 2, that reset/idle code should be implemented. This process will ensure both that users with "old" OMAP4 bootloaders -- really, u-boot versions distributed less than a year ago, so not very old at all -- will be able to successfully enter chip low power states. It will also ensure that users who boot to new kernels with kexec will be able to do so successfully, with a minimum of interference from other devices. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, Mar 26, 2013 at 04:16:10PM +, Grant Likely wrote: > On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou > wrote: > > Hi Lee, > > > > On Jan 8, 2013, at 12:00 PM, Lee Jones wrote: > > > > > At the end of the line, some kind of hardware glue is going to be > > > needed. > > > > > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to > > > throw > > > in the beagleboard), it is a bit premature to think about making it > > > overly > > > general, besides the part that are obviously part of the > > > infrastructure > > > (like the DT overlay stuff). > > > > > > What I'm getting at, is that we need some user experience about this, > > > before > > > going away and creating structure out of possible misconception about > > > the uses. > > > > IMHO stuff like this will be needed by many SoCs. Some examples of > > similar > > things for omaps that have eventually become generic frameworks have > > been > > the clock framework, USB OTG support, runtime PM, pinmux framework and > > so on. > > > > So I suggest a minimal generic API from the start as that will make > > things > > a lot easier in the long run. > > >>> > > >>> I agree. The ux500 platform already has the concept of "user interface > > >>> boards", > > >>> which currently is not well integrated into devicetree. I believe Sascha > > >>> mentioned that Pengutronix had been shipping some other systems with > > >>> add-on > > >>> boards and generating device tree binaries from source for each > > >>> combination. > > >>> > > >>> Ideally, both of the above should be able to use the same DT overlay > > >>> logic > > >>> as BeagleBone, and I'm sure there are more of those. > > >> > > >> Hmm, I see. > > >> > > >> I will need some more information about the interface of the 'user > > >> interface boards'. > > >> I.e. how is the board identified, what is typically present on those > > >> boards, etc. > > > > > > User Interface Boards are mearly removable PCBs which are interchangeable > > > amongst various hardware platforms. They are connected via numerous > > > connectors which carry all sorts of different data links; i2c, spi, rs232, > > > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key > > > pad, leds, jumpers, switches and a bunch of sensors. > > > > > > You can find a small example of how we interface to these by viewing > > > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we > > > currently include it as a *.dtsi from a platform's dts file. > > > > I see. What I'm asking about is whether there's a method where you can read > > an EEPROM, or some GPIO code combination where I can find out what kind of > > board > > is plugged each time. > > > > If there is not, there is no way to automatically load the overlays; you > > can always > > use the kernel command line, or have the a user space application to > > request the loading > > of a specific board's overlay. > > > > In this case the best thing to do is announce the availability of the > expansion via a request_firmware() call and let udev handle supplying > the correct overlay file. The code to load firmware files was recently removed from udev, now that the kernel handles this automatically itself :) But yes, the same call still applies, request_firmware() should work fine here. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou wrote: > Hi Lee, > > On Jan 8, 2013, at 12:00 PM, Lee Jones wrote: > > > At the end of the line, some kind of hardware glue is going to be > > needed. > > > > I just feel that drawing from a sample size of 1 (maybe 2 if I get to > > throw > > in the beagleboard), it is a bit premature to think about making it > > overly > > general, besides the part that are obviously part of the infrastructure > > (like the DT overlay stuff). > > > > What I'm getting at, is that we need some user experience about this, > > before > > going away and creating structure out of possible misconception about > > the uses. > > IMHO stuff like this will be needed by many SoCs. Some examples of > similar > things for omaps that have eventually become generic frameworks have been > the clock framework, USB OTG support, runtime PM, pinmux framework and > so on. > > So I suggest a minimal generic API from the start as that will make > things > a lot easier in the long run. > >>> > >>> I agree. The ux500 platform already has the concept of "user interface > >>> boards", > >>> which currently is not well integrated into devicetree. I believe Sascha > >>> mentioned that Pengutronix had been shipping some other systems with > >>> add-on > >>> boards and generating device tree binaries from source for each > >>> combination. > >>> > >>> Ideally, both of the above should be able to use the same DT overlay logic > >>> as BeagleBone, and I'm sure there are more of those. > >> > >> Hmm, I see. > >> > >> I will need some more information about the interface of the 'user > >> interface boards'. > >> I.e. how is the board identified, what is typically present on those > >> boards, etc. > > > > User Interface Boards are mearly removable PCBs which are interchangeable > > amongst various hardware platforms. They are connected via numerous > > connectors which carry all sorts of different data links; i2c, spi, rs232, > > etc. The UIB I'm looking at right now has a touchscreen, speakers, a key > > pad, leds, jumpers, switches and a bunch of sensors. > > > > You can find a small example of how we interface to these by viewing > > 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we > > currently include it as a *.dtsi from a platform's dts file. > > I see. What I'm asking about is whether there's a method where you can read > an EEPROM, or some GPIO code combination where I can find out what kind of > board > is plugged each time. > > If there is not, there is no way to automatically load the overlays; you can > always > use the kernel command line, or have the a user space application to request > the loading > of a specific board's overlay. > In this case the best thing to do is announce the availability of the expansion via a request_firmware() call and let udev handle supplying the correct overlay file. 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 2/5] capemgr: Add beaglebone's cape driver bindings
On Mon, 7 Jan 2013 20:51:03 +0200, Pantelis Antoniou
wrote:
> Document the beaglebone's cape driver bindings.
>
> Signed-off-by: Pantelis Antoniou
Hi Pantelis,
I'll go back and review the driver in a minute, but I'll start here
since this is the data model that we'll be using for a long time.
Overall this looks pretty sane. It's pretty well contained too which I
like. Long term I do want to try and create some common patterns for
overlay connections, but it's really hard to do that when this is the
first serious attempt at implementing one. :-) This is nicely contained
to only the beaglebone use case which makes it easy to try out without
forcing this exact data model on all users. If it works in other places,
then fantastic! we've got our generic model. If not, then we can refine
the interface for new boards without breaking beaglebone.
Comments below...
> ---
> .../devicetree/bindings/misc/capes-beaglebone.txt | 110
> +
> 1 file changed, 110 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/misc/capes-beaglebone.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> new file mode 100644
> index 000..f73cab5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/capes-beaglebone.txt
> @@ -0,0 +1,110 @@
> +* TI Beaglebone DT Overlay Cape Driver
> +
> +Required properties:
> +
> +- compatible: "ti,bone-capemgr"
"capemgr" sounds like a software construct. Can you rename this to
something that sounds more like describing concrete hardware? From that
perspective, "ti,bone-capebus" would be appropriate here, regardless of
where the driver actually lives in the kernel tree.
It would be better to be more specific here with the compatible
property also. Put the actual board name into the compatible string.
Following the lead of the board level compatible property, call it
'ti,am335x-bone-capebus". Newer boards can claim compatibilty with the
older where appropriate.
> +
> +- eeprom: Contains the phandle beaglebone's baseboard i2c eeprom.
> +
> +- baseboardmaps - node containing a list of supported
> + beaglebone revisions; each node in should have the
> + following properties:
> + - board-name: The board name stored in the baseboard
> + eeprom.
If it is stored in the baseboard eeprom, then why does it need to appear
in the .dtb?
> + - compatible-name: The name which will be used for
> + matching compatible capes.
What is the matching logic for this compatible capes? How does it get
used?
> +
> +- slots: node containing a list of slot nodes (which in the beaglebone
> + case correspond to I2C addresses for dynamically probed capes,
> + or an override slot definition for hardcoded capes.
> + - eeprom: Contains the phandle beaglebone's cape i2c eeprom.
> +
> + It is possible to define override slots that will be activated
> + when the baseboard matches, and/or if supplied on the kernel command
> + line and/or when dynamically requested on runtime.
> + In that case the slot is marked with
> + - ti,cape-override: Marks a slot override.
> + - compatible: any of the "runtime", "kernel", or any compatible-name
> + on a matching baseboardmap node.
> + - Any of the eeprom-format-revision, board-name, version, manufacturer,
> + part-number, number-of-pins, serial-number, pin-usage, vdd-3v3exp,
> + vdd-5v, sys-5v, dc-supplied properties which fill in the simulated
> + cape's EEPROM fields. The part-number field is required, the rest
> + are optional taking into default values.
I could use some help understanding the use-case for the override slots.
It isn't clear to me how the override is intended to work. Can you
describe exactly what happens when an override slot is defined? Do
override slots replace detected slots, or are they separate?
> +
> +- capemaps: node contains list of cape mappings, which allow converting
> + from a part-number & version tuple to the filename of the dtbo file.
> + - part-number: part number contained in the EEPROM
> + - version node containing a
> + - version: specific version to map to
> + - dtbo: name of the dtbo file
I think you'd be better off here defining a direct 1:1 mapping from
board name + revision to dtb filename. Maintaining a list of mappings in
the dtb file means it needs to be updated when new capes are created. It
would be nicer to drop the new overlay in the root filesystem (or initrd
if that is more convenient) and have the kernel know when to pick it up.
> +
> +Example:
> +bone_capemgr {
> + compatible = "ti,bone-capemgr";
> + status = "okay";
> +
> + eeprom = <&baseboard_eeprom>;
> +
> + baseboardmaps {
> + baseboard_beaglebone: board@0 {
> + board-name = "A335BONE";
> + compatible-name = "ti,beag
Re: OMAP baseline test results for v3.9-rc3
Hi On Tue, 19 Mar 2013, Santosh Shilimkar wrote: > On Monday 18 March 2013 09:08 PM, Paul Walmsley wrote: > > > Test summary > > > > > Thanks for the summary Paul. A usual, it is quite exhaustive. Would that it were true. These tests are really only very superficial. Here are some major missing areas: - other devices (audio, video, etc.) - stability testing - does the board hang or freeze across 24 hours to a week of uptime? - CPU DVFS - current consumption during active, ret idle, off idle - multiple bootloaders - multiple rootfs originations (across boards that support several) -- e.g., NFS, MMC, etc. If I were basing anything off the mainline kernel, that's the minimum I'd like to see. > > > > * 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE > > > I thought we discussed about boot-loader dependency already. > > > * 4460pandaes: pwrdm state mismatch on IVAHD, TESLA > > > Same here. Have these issues been confirmed to be bootloader-related? If so, then we can mark these as cases where the kernel isn't resetting devices properly. > > * 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state > > - Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB > > per discussion with Tero Kristo > > - Likely dependent on the bootloader version > > - fails with 2012.07-00136-g755de79 > > > Do you still see the issue after upgrading the boot-loader version ? Haven't tried yet. > > * 4460pandaes: chip not entering retention in dynamic idle > > - Presumably 4430es2panda also fails this > > - Suspend-to-RAM enters full chip retention > > > Assuming dynmic idle is CPUIdle, core retention isn't supported > in CPUDILE so it is expected No, it's not CPUIdle. It's simply echoing a power management timeout to the UART autosuspend sysfs entries. You can see exactly what's done by checking the pm/ directory in the test logs, for example: http://www.pwsan.com/omap/testlogs/test_v3.9-rc4/20130324120244/pm/ OMAP4 should be able to enter full-chip retention idle without CPUIdle, as OMAP3 does. If the current kernel depends on CPUIdle to do this on OMAP4, that's a bug. > > Other: > > > > * 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed > > - Unknown cause; could be due to the lack of hierarchical enable/disable > > in hwmod code > > - Jon Hunter reports this does not appear with the same > > X-loader/bootloader > > on his 4430ES2.3 Panda, so could be ES-level dependent > I confirm Jon's observation even on my OMAP4430 ES2.3 SDP. Thanks, I put this in the v3.9-rc4 README. - 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
OMAP baseline test results for v3.9-rc4
Here are some basic OMAP test results for Linux v3.9-rc4.
Logs and other details at:
http://www.pwsan.com/omap/testlogs/test_v3.9-rc4/20130324120244/
Test summary
Build:
FAIL ( 3/16): am33xx_only, omap1_defconfig_5912osk_only,
omap2plus_defconfig_2430sdp_only
Pass (13/16): n800_multi_omap2xxx, n800_only_a, omap1_defconfig,
omap1_defconfig_1510innovator_only,
omap2plus_defconfig, omap2plus_defconfig_cpupm,
omap2plus_defconfig_no_pm,
omap2plus_defconfig_omap2_4_only,
omap2plus_defconfig_omap3_4_only,
rmk_omap3430_ldp_allnoconfig,
rmk_omap3430_ldp_oldconfig,
rmk_omap4430_sdp_allnoconfig
rmk_omap4430_sdp_oldconfig
Boot to userspace:
FAIL ( 1/11): am335xbone
Pass (10/11): 2420n800, 2430sdp, 3517evm, 3530es3beagle,
3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes,
5912osk, cmt3517
PM ret, suspend:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM ret, dynamic idle:
FAIL ( 4/ 6): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 6): 3530es3beagle, 3730beaglexm
PM off, suspend:
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
PM off, dynamic idle:
FAIL ( 3/ 5): 37xxevm, 4430es2panda, 4460pandaes
Pass ( 2/ 5): 3530es3beagle, 3730beaglexm
Failing tests: fixed by posted patches
--
Build:
* omap1_defconfig_5912osk_only: implicit declaration of function
'cpu_is_omap15xx'
- Fixed by Aaro: http://www.spinics.net/lists/linux-omap/msg87523.html
* am33xx_only, omap2plus_defconfig_2430sdp_only: omap-{smp,hotplug}.c link
errors
- Discussion & RFC patch:
http://www.spinics.net/lists/arm-kernel/msg230017.html
PM:
* 4460pandaes: CORE, L3INIT didn't enter target state
- Caused by 17b7e7d33530e2bbd3bdc90f4db09b91cfdde2bb
(ARM: OMAP4: clock/hwmod data: start to remove some IP block control
"clocks")
- Fixed by "ARM: OMAP4: PM: fix PM regression introduced by recent clock
cleanup"
- http://www.spinics.net/lists/arm-kernel/msg224419.html
Failing tests: needing investigation
Boot tests:
* 3517EVM & CM-T3517: boot hangs with NFS root
- Likely some Kconfig, board file, and PM issues with EMAC
- Longstanding bug
Boot warnings:
* 2430sdp & 37xxevm: nasty lock warning due to NFS root
- Cause unknown
- Breaks most remaining tests
* CM-T3517: L3 in-band error with IPSS during boot
- Cause unknown but see http://marc.info/?l=linux-omap&m=134833869730129&w=2
- Longstanding issue; does not occur on the 3517EVM
PM tests:
* 2430sdp: pwrdm state mismatch(dsp_pwrdm) 0 != 3
- need to doublecheck wakeup dependencies
- (am assuming it's still there; userspace problems prevent the test
from running, probably due to the lock warning)
* 2430sdp: power domains not entering retention
- Cause unknown
- (am assuming it's still there; userspace problems prevent the test
from running, probably due to the lock warning)
* 4430es2panda, 4460pandaes: pwrdm state mismatch on CAM, DSS, ABE
* 4460pandaes: pwrdm state mismatch on IVAHD, TESLA
* 4430es2panda: CORE, TESLA, IVAHD, L3INIT didn't enter target state
- Probably due to lack of reset code for M3, DSP, SL2IF, FSUSB
per discussion with Tero Kristo
- Likely dependent on the bootloader version
- fails with 2012.07-00136-g755de79
* 4460pandaes: chip not entering retention in dynamic idle
- Presumably 4430es2panda also fails this
- Suspend-to-RAM enters full chip retention
* 3730 Beagle XM: does not serial wake from off-idle suspend when console
UART doesn't clock-gate ("debug ignore_loglevel")
- Cause unknown
- Not yet part of the automated test suite
- Re-tested at v3.7; still failing:
http://www.pwsan.com/omap/transcripts/20121211-3730beaglexm-3.7-pm-offmode-fail-debug.txt
Other:
* 4430es2panda: omap_hwmod: l3_instr: _wait_target_disable failed
- Unknown cause; could be due to the lack of hierarchical enable/disable
in hwmod code
- Jon Hunter and Santosh Shilimkar report this does not appear with
the same X-loader/bootloader on his 4430ES2.3 Panda, so could be
ES-level dependent
vmlinux object size
(delta in bytes from test_v3.9-rc3
(a937536b868b8369b98967929045f1df54234323)):
text data bsstotal kernel
+188 +640 +252 n800_multi_omap2xxx
+188 +640 +252 n800_only_a
+972 +640+1036 omap1_defconfig
+956 +640+1020 omap1_defconfig_1510innovator_only
+225600+2256 omap2plus_defconfig
+225600+2256 omap2plus_defconfig_cpupm
+2192 +640+2256 omap2plus_defconfig_no_pm
+2320
Re: [PATCH] ARM: AM33XX: Add missing .clkdm_name to clkdiv32k_ick clock
On Mon, 25 Mar 2013, Vaibhav Hiremath wrote: > During common-clock migration, .clkdm_name field got missed > for "clkdiv32k_ick" clock, which leaves "clk_24mhz_clkdm" > unused; so boot process will try to disable the clockdomain > even childs of this clock is enabled, which keeps child modules > in idle mode. Looks fine to me. You're planning to update the patch description, right? So should I wait until you repost it? Also you should probably trim the crash log after "[2.626025] LR is at clk_enable+0x30/0x3c" - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On 03/26/2013 03:29 PM, Benoit Cousson wrote:
> On 03/26/2013 03:10 PM, Benoit Cousson wrote:
>> Hi Javier,
>>
>> On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
>>> On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
>>> wrote:
The binding documentation for the OMAP GPIO controller has the
"#interrupt-cells" property listed before "#interrupt-controller"
property but its description after.
This is confusing so we move "#interrupt-cells" after the
"interrupt-controller" property so is followed by its description.
While being there, change the properties order to be consistent with
Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
and Documentation/devicetree/bindings/gpio/gpio.txt.
According with these docs, the order of the properties for a gpio-omap
device node should be:
gpio-controller;
#gpio-cells = <2>;
interrupt-controller;
#interrupt-cells = <2>;
Reported-by: Stephen Warren
Signed-off-by: Javier Martinez Canillas
Acked-by: Jon Hunter
---
Changes since v1:
- Change the properties order to be consistent with the rest of the
DT bindings docs suggested by Jon Hunter.
Changes since v2:
- Fix changelog that explained the opposite of what the patch was doing
as
suggested by Benoit Cousson.
.../devicetree/bindings/gpio/gpio-omap.txt |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
index bff51a2..a56e3a5 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
@@ -5,12 +5,12 @@ Required properties:
- "ti,omap2-gpio" for OMAP2 controllers
- "ti,omap3-gpio" for OMAP3 controllers
- "ti,omap4-gpio" for OMAP4 controllers
+- gpio-controller : Marks the device node as a GPIO controller.
- #gpio-cells : Should be two.
- first cell is the pin number
- second cell is used to specify optional parameters (unused)
-- gpio-controller : Marks the device node as a GPIO controller.
+- interrupt-controller: Mark the device node as an interrupt controller.
- #interrupt-cells : Should be 2.
-- interrupt-controller: Mark the device node as an interrupt controller
The first cell is the GPIO number.
The second cell is used to specify flags:
bits[3:0] trigger type and level flags:
@@ -29,8 +29,8 @@ Example:
gpio4: gpio4 {
compatible = "ti,omap4-gpio";
ti,hwmods = "gpio4";
-#gpio-cells = <2>;
gpio-controller;
-#interrupt-cells = <2>;
+#gpio-cells = <2>;
interrupt-controller;
+#interrupt-cells = <2>;
};
--
1.7.7.6
>>>
>>> Hello,
>>>
>>> any comments on this patch?
>>
>> That's perfect. I've just applied it in my branch.
>
> OK, in fact it is almost perfect :-)
>
> The patch modified the documentation and not the driver itself, so I modified
> the subject to reflect that accurately.
>
> Documentation: dt: gpio-omap: Move interrupt-controller from #interrupt-cell
>
Sorry about that, this pattern was not evident for me by looking the Git logs.
Now I know for future patches.
Thanks a lot for pointing this out!
> Regards,
> Benoit
>
>
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/11] ARM: dts: OMAP5: ocp address space and few updates for 3.10
On Tuesday 26 March 2013 08:01 PM, Benoit Cousson wrote: > Hi Santosh, > > The series looks good to me. I've just applied it and update my branch. > > I just slightly modified some changelog to fix typos. > Thanks Benoit !! Will pull your updated branch. 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 v2 00/11] ARM: dts: OMAP5: ocp address space and few updates for 3.10
Hi Santosh, The series looks good to me. I've just applied it and update my branch. I just slightly modified some changelog to fix typos. Thanks, Benoit On 03/19/2013 02:30 PM, Santosh Shilimkar wrote: > Benoit, > > Here is the branch rebased and updated against your 'for_3.10/dt' branch. > Few minor updates about ocp/l3 node after our discussion at connect from > last version. The series also contains couple of hwmod patches to deal > with ocp address space from dt blob and avoiding iormap for some of > the hwmods. > > It has been tested on OMAP4 and OMAP5 devices. Though for OMAP5 testing, data > files and other patches are needed which are also targeted for 3.10 merge > window. > > The following changes since commit 44fab7a60d4c3929a04b7dc882ac1143b3f21b0f: > > ARM: dts: omap3-devkit8000: Add NAND DT node (2013-03-18 15:01:23 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux.git > for_3.10/omap_dt_update > > for you to fetch changes up to c0c153b52b9ed4965b7496e462b2effa3e4fa9ce: > > ARM: OMAP2+: omap_hwmod: Don't call _init_mpu_rt_base if no sysc > (2013-03-19 17:11:39 +0530) > > > > Lokesh Vutla (1): > ARM: dts: OMAP5: Add watchdog timer node > > Rajendra Nayak (1): > ARM: dts: OMAP5: Specify nonsecure PPI IRQ for arch timer > > Santosh Shilimkar (9): > ARM: dts: omap5-evm: Update available memory to 2032 MB > ARM: dts: OMAP5: Align the local timer dt node as per the current > binding code > ARM: dts: OMAP5: Move the gic node out of ocp space > ARM: dts: OMAP5: Update the timer and gic nodes for HYP kernel > support > ARM: dts: OMAP5: Update keypad reg property > Documentation: dt: OMAP: l3-noc: Add *reg* in required properties > ARM: dts: OMAP4/5: Update l3-noc dt nodes > ARM: OMAP2+: hwmod: extract module address space from DT blob > ARM: OMAP2+: omap_hwmod: Don't call _init_mpu_rt_base if no sysc > > .../devicetree/bindings/arm/omap/l3-noc.txt|1 + > arch/arm/boot/dts/omap4.dtsi |5 ++ > arch/arm/boot/dts/omap5-evm.dts|2 +- > arch/arm/boot/dts/omap5.dtsi | 56 > +--- > arch/arm/mach-omap2/omap_hwmod.c | 48 +++-- > 5 files changed, 87 insertions(+), 25 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 v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On 03/26/2013 03:10 PM, Benoit Cousson wrote:
> Hi Javier,
>
> On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
>> On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
>> wrote:
>>> The binding documentation for the OMAP GPIO controller has the
>>> "#interrupt-cells" property listed before "#interrupt-controller"
>>> property but its description after.
>>> This is confusing so we move "#interrupt-cells" after the
>>> "interrupt-controller" property so is followed by its description.
>>>
>>> While being there, change the properties order to be consistent with
>>> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>>> and Documentation/devicetree/bindings/gpio/gpio.txt.
>>>
>>> According with these docs, the order of the properties for a gpio-omap
>>> device node should be:
>>>
>>> gpio-controller;
>>> #gpio-cells = <2>;
>>> interrupt-controller;
>>> #interrupt-cells = <2>;
>>>
>>> Reported-by: Stephen Warren
>>> Signed-off-by: Javier Martinez Canillas
>>> Acked-by: Jon Hunter
>>> ---
>>>
>>> Changes since v1:
>>> - Change the properties order to be consistent with the rest of the
>>> DT bindings docs suggested by Jon Hunter.
>>>
>>> Changes since v2:
>>> - Fix changelog that explained the opposite of what the patch was doing as
>>> suggested by Benoit Cousson.
>>>
>>> .../devicetree/bindings/gpio/gpio-omap.txt |8
>>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>>> b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>>> index bff51a2..a56e3a5 100644
>>> --- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>>> @@ -5,12 +5,12 @@ Required properties:
>>>- "ti,omap2-gpio" for OMAP2 controllers
>>>- "ti,omap3-gpio" for OMAP3 controllers
>>>- "ti,omap4-gpio" for OMAP4 controllers
>>> +- gpio-controller : Marks the device node as a GPIO controller.
>>> - #gpio-cells : Should be two.
>>>- first cell is the pin number
>>>- second cell is used to specify optional parameters (unused)
>>> -- gpio-controller : Marks the device node as a GPIO controller.
>>> +- interrupt-controller: Mark the device node as an interrupt controller.
>>> - #interrupt-cells : Should be 2.
>>> -- interrupt-controller: Mark the device node as an interrupt controller
>>>The first cell is the GPIO number.
>>>The second cell is used to specify flags:
>>> bits[3:0] trigger type and level flags:
>>> @@ -29,8 +29,8 @@ Example:
>>> gpio4: gpio4 {
>>> compatible = "ti,omap4-gpio";
>>> ti,hwmods = "gpio4";
>>> -#gpio-cells = <2>;
>>> gpio-controller;
>>> -#interrupt-cells = <2>;
>>> +#gpio-cells = <2>;
>>> interrupt-controller;
>>> +#interrupt-cells = <2>;
>>> };
>>> --
>>> 1.7.7.6
>>>
>>
>> Hello,
>>
>> any comments on this patch?
>
> That's perfect. I've just applied it in my branch.
OK, in fact it is almost perfect :-)
The patch modified the documentation and not the driver itself, so I modified
the subject to reflect that accurately.
Documentation: dt: gpio-omap: Move interrupt-controller from #interrupt-cell
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: [PATCH] ASoC: omap: Call omap_mcbsp_set_threshold() from mcbsp hw_params
On Mon, Mar 25, 2013 at 04:58:16PM +0100, Lars-Peter Clausen wrote: > The omap PCM driver provides a set_threshold callback which gets called by the > PCM driver when either playback or capture is started. The only DAI driver > which > sets this callback is the mcbsp driver. This patch removes the callback from > the Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
Hi Javier,
On 03/26/2013 10:33 AM, Javier Martinez Canillas wrote:
> On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
> wrote:
>> The binding documentation for the OMAP GPIO controller has the
>> "#interrupt-cells" property listed before "#interrupt-controller"
>> property but its description after.
>> This is confusing so we move "#interrupt-cells" after the
>> "interrupt-controller" property so is followed by its description.
>>
>> While being there, change the properties order to be consistent with
>> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>> and Documentation/devicetree/bindings/gpio/gpio.txt.
>>
>> According with these docs, the order of the properties for a gpio-omap
>> device node should be:
>>
>> gpio-controller;
>> #gpio-cells = <2>;
>> interrupt-controller;
>> #interrupt-cells = <2>;
>>
>> Reported-by: Stephen Warren
>> Signed-off-by: Javier Martinez Canillas
>> Acked-by: Jon Hunter
>> ---
>>
>> Changes since v1:
>> - Change the properties order to be consistent with the rest of the
>> DT bindings docs suggested by Jon Hunter.
>>
>> Changes since v2:
>> - Fix changelog that explained the opposite of what the patch was doing as
>> suggested by Benoit Cousson.
>>
>> .../devicetree/bindings/gpio/gpio-omap.txt |8
>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>> b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>> index bff51a2..a56e3a5 100644
>> --- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
>> @@ -5,12 +5,12 @@ Required properties:
>>- "ti,omap2-gpio" for OMAP2 controllers
>>- "ti,omap3-gpio" for OMAP3 controllers
>>- "ti,omap4-gpio" for OMAP4 controllers
>> +- gpio-controller : Marks the device node as a GPIO controller.
>> - #gpio-cells : Should be two.
>>- first cell is the pin number
>>- second cell is used to specify optional parameters (unused)
>> -- gpio-controller : Marks the device node as a GPIO controller.
>> +- interrupt-controller: Mark the device node as an interrupt controller.
>> - #interrupt-cells : Should be 2.
>> -- interrupt-controller: Mark the device node as an interrupt controller
>>The first cell is the GPIO number.
>>The second cell is used to specify flags:
>> bits[3:0] trigger type and level flags:
>> @@ -29,8 +29,8 @@ Example:
>> gpio4: gpio4 {
>> compatible = "ti,omap4-gpio";
>> ti,hwmods = "gpio4";
>> -#gpio-cells = <2>;
>> gpio-controller;
>> -#interrupt-cells = <2>;
>> +#gpio-cells = <2>;
>> interrupt-controller;
>> +#interrupt-cells = <2>;
>> };
>> --
>> 1.7.7.6
>>
>
> Hello,
>
> any comments on this patch?
That's perfect. I've just applied it in my branch.
Thanks,
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
[PATCH v2 8/8] OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5
DISPC on OMAP5 has a more optimised mechanism of asserting Mstandby to achieve
more power savings when DISPC is configured in Smart Standby mode. This
mechanism leads to underflows when multiple DISPC pipes are enabled.
There is a register field which can let us revert to the older mechanism of
asserting Mstandby. Configure this field to prevent underflows.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dispc.c |7 +++
drivers/video/omap2/dss/dispc.h |1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index ddbf031..b33b016 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -87,6 +87,9 @@ struct dispc_features {
/* no DISPC_IRQ_FRAMEDONETV on this SoC */
bool no_framedone_tv:1;
+
+ /* revert to the OMAP4 mechanism of DISPC Smart Standby operation */
+ bool mstandby_workaround:1;
};
#define DISPC_MAX_NR_FIFOS 5
@@ -3502,6 +3505,9 @@ static void _omap_dispc_initial_config(void)
dispc_configure_burst_sizes();
dispc_ovl_enable_zorder_planes();
+
+ if (dispc.feat->mstandby_workaround)
+ REG_FLD_MOD(DISPC_MSTANDBY_CTRL, 1, 0, 0);
}
static const struct dispc_features omap24xx_dispc_feats __initconst = {
@@ -3596,6 +3602,7 @@ static const struct dispc_features omap54xx_dispc_feats
__initconst = {
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
.gfx_fifo_workaround= true,
+ .mstandby_workaround= true,
};
static int __init dispc_init_features(struct platform_device *pdev)
diff --git a/drivers/video/omap2/dss/dispc.h b/drivers/video/omap2/dss/dispc.h
index 222363c..de4863d 100644
--- a/drivers/video/omap2/dss/dispc.h
+++ b/drivers/video/omap2/dss/dispc.h
@@ -39,6 +39,7 @@
#define DISPC_GLOBAL_BUFFER0x0800
#define DISPC_CONTROL3 0x0848
#define DISPC_CONFIG3 0x084C
+#define DISPC_MSTANDBY_CTRL0x0858
/* DISPC overlay registers */
#define DISPC_OVL_BA0(n) (DISPC_OVL_BASE(n) + \
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers
Each version of OMAP has a limitation on the maximum pixel clock frequency
supported by an overlay manager. This limit isn't checked by omapdss. Add
dispc feats for lcd and tv managers and check whether the target timings can
be supported or not.
The pixel clock limitations are actually more complex. They depend on which OPP
OMAP is in, and they also depend on which encoder is the manager connected to.
The OPP dependence is ignored as DSS forces the PM framework to be on OPP100
when DSS is enabled, and the encoder dependencies are ignored by DISPC for now.
These limits should come from the encoder driver.
The OMAP2 TRM doesn't mention the maximum pixel clock limit. This value is left
as half of DSS_FCLK, as OMAP2 requires the PCD to be atleast 2.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dispc.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 8cfa27b..73a730a 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -69,6 +69,8 @@ struct dispc_features {
u8 mgr_height_start;
u16 mgr_width_max;
u16 mgr_height_max;
+ unsigned long max_lcd_pclk;
+ unsigned long max_tv_pclk;
int (*calc_scaling) (unsigned long pclk, unsigned long lclk,
const struct omap_video_timings *mgr_timings,
u16 width, u16 height, u16 out_width, u16 out_height,
@@ -2825,6 +2827,15 @@ static bool _dispc_lcd_timings_ok(int hsw, int hfp, int
hbp,
return true;
}
+static bool _dispc_mgr_pclk_ok(enum omap_channel channel,
+ unsigned long pclk)
+{
+ if (dss_mgr_is_lcd(channel))
+ return pclk <= dispc.feat->max_lcd_pclk ? true : false;
+ else
+ return pclk <= dispc.feat->max_tv_pclk ? true : false;
+}
+
bool dispc_mgr_timings_ok(enum omap_channel channel,
const struct omap_video_timings *timings)
{
@@ -2832,11 +2843,13 @@ bool dispc_mgr_timings_ok(enum omap_channel channel,
timings_ok = _dispc_mgr_size_ok(timings->x_res, timings->y_res);
- if (dss_mgr_is_lcd(channel))
- timings_ok = timings_ok && _dispc_lcd_timings_ok(timings->hsw,
- timings->hfp, timings->hbp,
- timings->vsw, timings->vfp,
- timings->vbp);
+ timings_ok &= _dispc_mgr_pclk_ok(channel, timings->pixel_clock * 1000);
+
+ if (dss_mgr_is_lcd(channel)) {
+ timings_ok &= _dispc_lcd_timings_ok(timings->hsw, timings->hfp,
+ timings->hbp, timings->vsw, timings->vfp,
+ timings->vbp);
+ }
return timings_ok;
}
@@ -3491,6 +3504,7 @@ static const struct dispc_features omap24xx_dispc_feats
__initconst = {
.mgr_height_start = 26,
.mgr_width_max = 2048,
.mgr_height_max = 2048,
+ .max_lcd_pclk = 6650,
.calc_scaling = dispc_ovl_calc_scaling_24xx,
.calc_core_clk = calc_core_clk_24xx,
.num_fifos = 3,
@@ -3508,6 +3522,8 @@ static const struct dispc_features
omap34xx_rev1_0_dispc_feats __initconst = {
.mgr_height_start = 26,
.mgr_width_max = 2048,
.mgr_height_max = 2048,
+ .max_lcd_pclk = 17300,
+ .max_tv_pclk= 5900,
.calc_scaling = dispc_ovl_calc_scaling_34xx,
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
@@ -3525,6 +3541,8 @@ static const struct dispc_features
omap34xx_rev3_0_dispc_feats __initconst = {
.mgr_height_start = 26,
.mgr_width_max = 2048,
.mgr_height_max = 2048,
+ .max_lcd_pclk = 17300,
+ .max_tv_pclk= 5900,
.calc_scaling = dispc_ovl_calc_scaling_34xx,
.calc_core_clk = calc_core_clk_34xx,
.num_fifos = 3,
@@ -3542,6 +3560,8 @@ static const struct dispc_features omap44xx_dispc_feats
__initconst = {
.mgr_height_start = 26,
.mgr_width_max = 2048,
.mgr_height_max = 2048,
+ .max_lcd_pclk = 17000,
+ .max_tv_pclk= 185625000,
.calc_scaling = dispc_ovl_calc_scaling_44xx,
.calc_core_clk = calc_core_clk_44xx,
.num_fifos = 5,
@@ -3559,6 +3579,8 @@ static const struct dispc_features omap54xx_dispc_feats
__initconst = {
.mgr_height_start = 27,
[PATCH v2 7/8] OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers
When using a DISPC video pipeline to a fetch a NV12 buffer in a 2D container, we
need to set set a doublestride bit in the video pipe's ATTRIBUTES register. This
is needed because the stride for the UV plane(using a 16 bit Tiler container) is
double the stride for the Y plane(using a 8 bit Tiler container) for the 0 or
180 degree views. The ROW_INC register is meant for the Y plane, and the HW will
calculate the row increment needed for the UV plane by using double the stride
value based on whether this bit is set or not.
Set the bit when we are using a 2D Tiler buffer and when rotation is 0 or 180
degrees. The stride value is the same for 90 and 270 degree Tiler views, hence
the bit shouldn't be set.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dispc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 73a730a..ddbf031 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1588,6 +1588,7 @@ static void dispc_ovl_set_scaling(enum omap_plane plane,
}
static void dispc_ovl_set_rotation_attrs(enum omap_plane plane, u8 rotation,
+ enum omap_dss_rotation_type rotation_type,
bool mirroring, enum omap_color_mode color_mode)
{
bool row_repeat = false;
@@ -1638,6 +1639,15 @@ static void dispc_ovl_set_rotation_attrs(enum omap_plane
plane, u8 rotation,
if (dss_has_feature(FEAT_ROWREPEATENABLE))
REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane),
row_repeat ? 1 : 0, 18, 18);
+
+ if (color_mode == OMAP_DSS_COLOR_NV12) {
+ bool doublestride = (rotation_type == OMAP_DSS_ROT_TILER) &&
+ (rotation == OMAP_DSS_ROT_0 ||
+ rotation == OMAP_DSS_ROT_180);
+ /* DOUBLESTRIDE */
+ REG_FLD_MOD(DISPC_OVL_ATTRIBUTES(plane), doublestride, 22, 22);
+ }
+
}
static int color_mode_to_bpp(enum omap_color_mode color_mode)
@@ -2516,7 +2526,8 @@ static int dispc_ovl_setup_common(enum omap_plane plane,
dispc_ovl_set_vid_color_conv(plane, cconv);
}
- dispc_ovl_set_rotation_attrs(plane, rotation, mirror, color_mode);
+ dispc_ovl_set_rotation_attrs(plane, rotation, rotation_type, mirror,
+ color_mode);
dispc_ovl_set_zorder(plane, caps, zorder);
dispc_ovl_set_pre_mult_alpha(plane, caps, pre_mult_alpha);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/8] omapdss: Features: Fix some parameter ranges
Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because
some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only
OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the
DSI PLL Fint range, this was previously just copied from the OMAP4 param range
struct.
Fix the maximum DSS_FCLK on OMAP2, it's 133 Mhz according to the TRM.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dss_features.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index 7f791ae..77dbe0c 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -414,7 +414,7 @@ static const char * const omap5_dss_clk_source_names[] = {
};
static const struct dss_param_range omap2_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK]= { 0, 17300 },
+ [FEAT_PARAM_DSS_FCK]= { 0, 13300 },
[FEAT_PARAM_DSS_PCD]= { 2, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, 0 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, 0 },
@@ -459,15 +459,15 @@ static const struct dss_param_range
omap4_dss_param_range[] = {
};
static const struct dss_param_range omap5_dss_param_range[] = {
- [FEAT_PARAM_DSS_FCK]= { 0, 2 },
+ [FEAT_PARAM_DSS_FCK]= { 0, 20925 },
[FEAT_PARAM_DSS_PCD]= { 1, 255 },
[FEAT_PARAM_DSIPLL_REGN]= { 0, (1 << 8) - 1 },
[FEAT_PARAM_DSIPLL_REGM]= { 0, (1 << 12) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DISPC] = { 0, (1 << 5) - 1 },
[FEAT_PARAM_DSIPLL_REGM_DSI]= { 0, (1 << 5) - 1 },
- [FEAT_PARAM_DSIPLL_FINT]= { 50, 250 },
+ [FEAT_PARAM_DSIPLL_FINT]= { 15, 5200 },
[FEAT_PARAM_DSIPLL_LPDIV] = { 0, (1 << 13) - 1 },
- [FEAT_PARAM_DSI_FCK]= { 0, 17000 },
+ [FEAT_PARAM_DSI_FCK]= { 0, 20925 },
[FEAT_PARAM_DOWNSCALE] = { 1, 4 },
[FEAT_PARAM_LINEWIDTH] = { 1, 2048 },
};
--
1.7.10.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/8] drm/omap: Make fixed resolution panels work
The omapdrm driver requires omapdss panel drivers to expose ops like detect,
set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI
and SDI drivers. At some places, there are no checks to see if the panel driver
has these ops or not, and that leads to a crash.
The following things are done to make fixed panels work:
- The omap_connector's detect function is modified such that it considers panel
types which are generally fixed panels as always connected(provided the panel
driver doesn't have a detect op). Hence, the connector corresponding to these
panels is always in a 'connected' state.
- If a panel driver doesn't have a check_timings op, assume that it supports the
mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper function)
- The function omap_encoder_update shouldn't really do anything for fixed
resolution panels, make sure that it calls set_timings only if the panel
driver has one.
Signed-off-by: Archit Taneja
---
v3: clear the timings local variable first before using memcmp
v2: make sure the timings we try to set for a fixed resolution panel match the
panel's timings
drivers/gpu/drm/omapdrm/omap_connector.c | 27 +--
drivers/gpu/drm/omapdrm/omap_encoder.c | 17 +++--
2 files changed, 40 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
b/drivers/gpu/drm/omapdrm/omap_connector.c
index c451c41..912759d 100644
--- a/drivers/gpu/drm/omapdrm/omap_connector.c
+++ b/drivers/gpu/drm/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
} else {
ret = connector_status_unknown;
}
@@ -189,12 +194,30 @@ static int omap_connector_mode_valid(struct drm_connector
*connector,
struct omap_video_timings timings = {0};
struct drm_device *dev = connector->dev;
struct drm_display_mode *new_mode;
- int ret = MODE_BAD;
+ int r, ret = MODE_BAD;
copy_timings_drm_to_omap(&timings, mode);
mode->vrefresh = drm_mode_vrefresh(mode);
- if (!dssdrv->check_timings(dssdev, &timings)) {
+ /*
+* if the panel driver doesn't have a check_timings, it's most likely
+* a fixed resolution panel, check if the timings match with the
+* panel's timings
+*/
+ if (dssdrv->check_timings) {
+ r = dssdrv->check_timings(dssdev, &timings);
+ } else {
+ struct omap_video_timings t = {0};
+
+ dssdrv->get_timings(dssdev, &t);
+
+ if (memcmp(&timings, &t, sizeof(struct omap_video_timings)))
+ r = -EINVAL;
+ else
+ r = 0;
+ }
+
+ if (!r) {
/* check if vrefresh is still valid */
new_mode = drm_mode_duplicate(dev, mode);
new_mode->clock = timings.pixel_clock;
diff --git a/drivers/gpu/drm/omapdrm/omap_encoder.c
b/drivers/gpu/drm/omapdrm/omap_encoder.c
index d48df71..c29451b 100644
--- a/drivers/gpu/drm/omapdrm/omap_encoder.c
+++ b/drivers/gpu/drm/omapdrm/omap_encoder.c
@@ -135,13 +135,26 @@ int omap_encoder_update(struct drm_encoder *encoder,
dssdev->output->manager = mgr;
- ret = dssdrv->check_timings(dssdev, timings);
+ if (dssdrv->check_timings) {
+ ret = dssdrv->check_timings(dssdev, timings);
+ } else {
+ struct omap_video_timings t = {0};
+
+ dssdrv->get_timings(dssdev, &t);
+
+ if (memcmp(timings, &t, sizeof(struct omap_video_timings)))
+ ret = -EINVAL;
+ else
+ ret = 0;
+ }
+
if (ret) {
dev_err(dev->dev, "could not set timings: %d\n", ret);
return ret;
}
- dssdrv->set_timings(dssdev, timings);
+ if (dssdrv->set_timings)
+ dssdrv->set_timings(dssdev, timings);
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/8] omapdss: features: fixed supported outputs for OMAP4
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
yet, we require some muxing at the DSS level, and we also need to configure
the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
don't support that yet.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dss_features.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index d7d66ef..7f791ae 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -202,12 +202,10 @@ static const enum omap_dss_output_id
omap3630_dss_supported_outputs[] = {
static const enum omap_dss_output_id omap4_dss_supported_outputs[] = {
/* OMAP_DSS_CHANNEL_LCD */
- OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
- OMAP_DSS_OUTPUT_DSI1,
+ OMAP_DSS_OUTPUT_DBI | OMAP_DSS_OUTPUT_DSI1,
/* OMAP_DSS_CHANNEL_DIGIT */
- OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI |
- OMAP_DSS_OUTPUT_DPI,
+ OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI,
/* OMAP_DSS_CHANNEL_LCD2 */
OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/8] drm/omap: Fix and improve crtc and overlay manager correlation
The omapdrm driver currently takes a config/module arg to figure out the number
of crtcs it needs to create. We could create as many crtcs as there are overlay
managers in the DSS hardware, but we don't do that because each crtc eats up
one DSS overlay, and that reduces the number of planes we can attach to a single
crtc.
Since the number of crtcs may be lesser than the number of hardware overlay
managers, we need to figure out which overlay managers to use for our crtcs. The
current approach is to use pipe2chan(), which returns a higher numbered manager
for the crtc.
The problem with this approach is that it assumes that the overlay managers we
choose will connect to the encoders the platform's panels are going to use,
this isn't true, an overlay manager connects only to a few outputs/encoders, and
choosing any overlay manager for our crtc might lead to a situation where the
encoder cannot connect to any of the crtcs we have chosen. For example, an
omap5-panda board has just one hdmi output. If num_crtc is set to 1, with the
current approach, pipe2chan will pick up the LCD2 overlay manager, which cannot
connect to the hdmi encoder at all. The only manager that could have connected
to hdmi was the TV overlay manager.
Therefore, there is a need to choose our overlay managers keeping in mind the
panels we have on that platform. The new approach iterates through all the
available panels, creates encoders and connectors for them, and then tries to
get a suitable overlay manager to create a crtc which can connect to the
encoders.
We use the dispc_channel field in omap_dss_output to retrieve the desired
overlay manager's channel number, we then check whether the manager had already
been assigned to a crtc or not. If it was already assigned to a crtc, we assume
that out of all the encoders which intend use this crtc, only one will run at a
time. If the overlay manager wan't assigned to a crtc till then, we create a
new crtc and link it with the overlay manager.
This approach just looks for the best dispc_channel for each encoder. On DSS HW,
some encoders can connect to multiple overlay managers. Since we don't try
looking for alternate overlay managers, there is a greater possibility that 2
or more encoders end up asking for the same crtc, causing only one encoder to
run at a time.
Also, this approach isn't the most optimal one, it can do either good or bad
depending on the sequence in which the panels/outputs are parsed. The optimal
way would be some sort of back tracking approach, where we improve the set of
managers we use as we iterate through the list of panels/encoders. That's
something left for later.
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_crtc.c| 21 +++--
drivers/gpu/drm/omapdrm/omap_drv.c | 157 ++--
drivers/gpu/drm/omapdrm/omap_drv.h | 38 +---
drivers/gpu/drm/omapdrm/omap_encoder.c |7 ++
drivers/gpu/drm/omapdrm/omap_irq.c | 17 ++--
5 files changed, 165 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index bec66a4..79b200a 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -74,6 +74,13 @@ struct omap_crtc {
struct work_struct page_flip_work;
};
+uint32_t pipe2vbl(struct drm_crtc *crtc)
+{
+ struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
+
+ return dispc_mgr_get_vsync_irq(omap_crtc->channel);
+}
+
/*
* Manager-ops, callbacks from output when they need to configure
* the upstream part of the video pipe.
@@ -613,7 +620,13 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
omap_crtc->apply.pre_apply = omap_crtc_pre_apply;
omap_crtc->apply.post_apply = omap_crtc_post_apply;
- omap_crtc->apply_irq.irqmask = pipe2vbl(id);
+ omap_crtc->channel = channel;
+ omap_crtc->plane = plane;
+ omap_crtc->plane->crtc = crtc;
+ omap_crtc->name = channel_names[channel];
+ omap_crtc->pipe = id;
+
+ omap_crtc->apply_irq.irqmask = pipe2vbl(crtc);
omap_crtc->apply_irq.irq = omap_crtc_apply_irq;
omap_crtc->error_irq.irqmask =
@@ -621,12 +634,6 @@ struct drm_crtc *omap_crtc_init(struct drm_device *dev,
omap_crtc->error_irq.irq = omap_crtc_error_irq;
omap_irq_register(dev, &omap_crtc->error_irq);
- omap_crtc->channel = channel;
- omap_crtc->plane = plane;
- omap_crtc->plane->crtc = crtc;
- omap_crtc->name = channel_names[channel];
- omap_crtc->pipe = id;
-
/* temporary: */
omap_crtc->mgr.id = channel;
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 77b7225..cbaa003 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -74,49 +74,48 @@ static int get_connector_type(struct omap_dss_device
*dssdev)
}
}
+static bool channel_used(struct drm_device *dev, enum
[PATCH v2 1/8] drm/omap: Don't return from modeset_init if a panel doesn't satisfy omapdrm requirements
modeset_init iterates through all the registered omapdss devices and has some
initial checks to see if the panel has a driver and the required driver ops for
it to be usable by omapdrm.
The function bails out from modeset_init if a panel doesn't meet the
requirements, and stops the registration of the future panels and encoders which
come after it, that isn't the correct thing to do, we should go through the rest
of the panels. Replace the 'return's with 'continue's.
Reviewed-by: Rob Clark
Signed-off-by: Archit Taneja
---
drivers/gpu/drm/omapdrm/omap_drv.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 079c54c..77b7225 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -121,7 +121,7 @@ static int omap_modeset_init(struct drm_device *dev)
if (!dssdev->driver) {
dev_warn(dev->dev, "%s has no driver.. skipping it\n",
dssdev->name);
- return 0;
+ continue;
}
if (!(dssdev->driver->get_timings ||
@@ -129,7 +129,7 @@ static int omap_modeset_init(struct drm_device *dev)
dev_warn(dev->dev, "%s driver does not support "
"get_timings or read_edid.. skipping it!\n",
dssdev->name);
- return 0;
+ continue;
}
encoder = omap_encoder_init(dev, dssdev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements
These are misc fixes and improvements within omapdrm and omapdss. The fixes do the following: - Make omapdrm smarter to choose the right overlay managers as it's crtcs. This makes sure that omapdrm is functional for OMAP platforms with different combinations of panels connected to it. - Fix certain areas in omapdrm which allow fixed resolution panels to work. - Fix functional and pixel clock limits for DISPC, this ensures we don't try to try a mode that the hardware can't support. - Some changes that came in OMAP5 ES2 silicon. Note: The branch is based on the DSS misc series and dsi video mode calc series posted by Tomi. Reference branch: git://gitorious.org/~boddob/linux-omap-dss2/archit-dss2-clone.git for-3.10/misc_drm_dss Archit Taneja (8): drm/omap: Don't return from modeset_init if a panel doesn't satisfy omapdrm requirements drm/omap: Fix and improve crtc and overlay manager correlation drm/omap: Make fixed resolution panels work omapdss: features: fixed supported outputs for OMAP4 omapdss: DISPC: add max pixel clock limits for LCD and TV managers omapdss: Features: Fix some parameter ranges OMAPDSS: DISPC: Configure doublestride for NV12 when using 2D Tiler buffers OMAPDSS: DISPC: Revert to older DISPC Smart Standby mechanism for OMAP5 drivers/gpu/drm/omapdrm/omap_connector.c | 27 - drivers/gpu/drm/omapdrm/omap_crtc.c | 21 ++-- drivers/gpu/drm/omapdrm/omap_drv.c | 161 -- drivers/gpu/drm/omapdrm/omap_drv.h | 38 +-- drivers/gpu/drm/omapdrm/omap_encoder.c | 24 - drivers/gpu/drm/omapdrm/omap_irq.c | 17 ++-- drivers/video/omap2/dss/dispc.c | 52 -- drivers/video/omap2/dss/dispc.h |1 + drivers/video/omap2/dss/dss_features.c | 14 ++- 9 files changed, 260 insertions(+), 95 deletions(-) -- 1.7.10.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 26/26] ARM: OMAP: Overo: use new generic-dpi-panel platform driver
Use the new generic-dpi-panel platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/board-overo.c | 71 +++--
1 file changed, 36 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index e3cd2bd..21579f8 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -152,6 +152,41 @@ static int dvi_enabled;
#define OVERO_GPIO_LCD_EN 144
#define OVERO_GPIO_LCD_BL 145
+static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ if (dvi_enabled) {
+ printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
+ return -EINVAL;
+ }
+
+ gpio_set_value(OVERO_GPIO_LCD_EN, 1);
+ gpio_set_value(OVERO_GPIO_LCD_BL, 1);
+ lcd_enabled = 1;
+ return 0;
+}
+
+static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ gpio_set_value(OVERO_GPIO_LCD_EN, 0);
+ gpio_set_value(OVERO_GPIO_LCD_BL, 0);
+ lcd_enabled = 0;
+}
+
+static struct panel_generic_dpi_data overo_lcd43_data = {
+ .display_name = "lcd43",
+ .source = "dpi.0",
+ .name = "samsung_lte430wq_f0c",
+ .platform_enable= overo_panel_enable_lcd,
+ .platform_disable = overo_panel_disable_lcd,
+ .data_lines = 24,
+};
+
+static struct platform_device overo_lcd43_device = {
+ .name = "generic_dpi_panel",
+ .id = 0,
+ .dev.platform_data = &overo_lcd43_data,
+};
+
static struct gpio overo_dss_gpios[] __initdata = {
{ OVERO_GPIO_LCD_EN, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_EN" },
{ OVERO_GPIO_LCD_BL, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_BL" },
@@ -182,6 +217,7 @@ static void __init overo_display_init(void)
gpio_export(OVERO_GPIO_LCD_BL, 0);
platform_device_register(&overo_dvi_device);
+ platform_device_register(&overo_lcd43_device);
}
static struct omap_dss_device overo_tv_device = {
@@ -191,40 +227,6 @@ static struct omap_dss_device overo_tv_device = {
.phy.venc.type = OMAP_DSS_VENC_TYPE_SVIDEO,
};
-static int overo_panel_enable_lcd(struct omap_dss_device *dssdev)
-{
- if (dvi_enabled) {
- printk(KERN_ERR "cannot enable LCD, DVI is enabled\n");
- return -EINVAL;
- }
-
- gpio_set_value(OVERO_GPIO_LCD_EN, 1);
- gpio_set_value(OVERO_GPIO_LCD_BL, 1);
- lcd_enabled = 1;
- return 0;
-}
-
-static void overo_panel_disable_lcd(struct omap_dss_device *dssdev)
-{
- gpio_set_value(OVERO_GPIO_LCD_EN, 0);
- gpio_set_value(OVERO_GPIO_LCD_BL, 0);
- lcd_enabled = 0;
-}
-
-static struct panel_generic_dpi_data lcd43_panel = {
- .name = "samsung_lte430wq_f0c",
- .platform_enable= overo_panel_enable_lcd,
- .platform_disable = overo_panel_disable_lcd,
-};
-
-static struct omap_dss_device overo_lcd43_device = {
- .name = "lcd43",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name= "generic_dpi_panel",
- .data = &lcd43_panel,
- .phy.dpi.data_lines = 24,
-};
-
#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
static struct omap_dss_device overo_lcd35_device = {
@@ -243,7 +245,6 @@ static struct omap_dss_device *overo_dss_devices[] = {
defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
&overo_lcd35_device,
#endif
- &overo_lcd43_device,
};
static struct omap_dss_board_info overo_dss_data = {
--
1.7.10.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 06/26] OMAPDSS: SDI: fix regulators
SDI requires a regulator to operate. This regulator is, for some reason,
currently attached to the virtual omapdss device, instead of the SDI
device. This does not work for DT, as the regulator mappings need to be
described in the DT data, and the virtual omapdss device is not present
there.
Fix the issue by acquiring the regulator in the SDI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to SDI.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/sdi.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index 0155c7e..607244a 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -31,8 +31,11 @@
#include "dss.h"
static struct {
+ struct platform_device *pdev;
+
bool update_enabled;
struct regulator *vdds_sdi_reg;
+ bool vdds_sdi_from_core;
struct dss_lcd_mgr_config mgr_config;
struct omap_video_timings timings;
@@ -258,8 +261,14 @@ static int __init sdi_init_display(struct omap_dss_device
*dssdev)
vdds_sdi = dss_get_vdds_sdi();
if (IS_ERR(vdds_sdi)) {
- DSSERR("can't get VDDS_SDI regulator\n");
- return PTR_ERR(vdds_sdi);
+ vdds_sdi = regulator_get(&sdi.pdev->dev, "vdds_sdi");
+ if (IS_ERR(vdds_sdi)) {
+ DSSERR("can't get VDDS_SDI regulator\n");
+ return PTR_ERR(vdds_sdi);
+ }
+ sdi.vdds_sdi_from_core = false;
+ } else {
+ sdi.vdds_sdi_from_core = true;
}
sdi.vdds_sdi_reg = vdds_sdi;
@@ -359,6 +368,8 @@ static void __exit sdi_uninit_output(struct platform_device
*pdev)
static int __init omap_sdi_probe(struct platform_device *pdev)
{
+ sdi.pdev = pdev;
+
sdi_init_output(pdev);
if (pdev->dev.platform_data)
@@ -373,6 +384,11 @@ static int __exit omap_sdi_remove(struct platform_device
*pdev)
sdi_uninit_output(pdev);
+ if (sdi.vdds_sdi_reg != NULL && sdi.vdds_sdi_from_core == false) {
+ regulator_put(sdi.vdds_sdi_reg);
+ sdi.vdds_sdi_reg = NULL;
+ }
+
return 0;
}
--
1.7.10.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 16/26] OMAPDSS: TFP410: convert to platform device
Convert TFP410 driver from omap_dss_driver to a platform driver. The
driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/panel-tfp410.c | 205 +--
1 file changed, 128 insertions(+), 77 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tfp410.c
b/drivers/video/omap2/displays/panel-tfp410.c
index 8281baa..a225ea1 100644
--- a/drivers/video/omap2/displays/panel-tfp410.c
+++ b/drivers/video/omap2/displays/panel-tfp410.c
@@ -22,10 +22,13 @@
#include
#include
#include
+#include
#include
#include
+static struct omap_dss_driver tfp410_driver;
+
static const struct omap_video_timings tfp410_default_timings = {
.x_res = 640,
.y_res = 480,
@@ -48,121 +51,152 @@ static const struct omap_video_timings
tfp410_default_timings = {
};
struct panel_drv_data {
- struct omap_dss_device *dssdev;
+ struct omap_dss_device dssdev;
struct mutex lock;
+ const char *name;
+
int pd_gpio;
+ int data_lines;
+
+ struct omap_video_timings timings;
struct i2c_adapter *i2c_adapter;
};
-static int tfp410_power_on(struct omap_dss_device *dssdev)
+#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
+
+static int tfp410_probe_pdata(struct platform_device *pdev)
{
- struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
- int r;
+ struct tfp410_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ struct panel_drv_data *ddata = dev_get_drvdata(&pdev->dev);
+ int r, gpio, i2c_bus_num;
- if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
- return 0;
+ ddata->name = pdata->name;
- omapdss_dpi_set_timings(dssdev, &dssdev->panel.timings);
- omapdss_dpi_set_data_lines(dssdev, dssdev->phy.dpi.data_lines);
+ gpio = pdata->power_down_gpio;
- r = omapdss_dpi_display_enable(dssdev);
- if (r)
- goto err0;
+ if (gpio_is_valid(gpio)) {
+ r = devm_gpio_request_one(&pdev->dev, gpio,
+ GPIOF_OUT_INIT_LOW, "tfp410 pd");
+ if (r) {
+ dev_err(&pdev->dev, "Failed to request PD GPIO %d\n",
+ gpio);
+ return r;
+ }
- if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value_cansleep(ddata->pd_gpio, 1);
+ ddata->pd_gpio = gpio;
+ } else {
+ ddata->pd_gpio = -1;
+ }
- return 0;
-err0:
- return r;
-}
+ ddata->data_lines = pdata->data_lines;
-static void tfp410_power_off(struct omap_dss_device *dssdev)
-{
- struct panel_drv_data *ddata = dev_get_drvdata(&dssdev->dev);
+ i2c_bus_num = pdata->i2c_bus_num;
- if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
- return;
+ if (i2c_bus_num != -1) {
+ struct i2c_adapter *adapter;
- if (gpio_is_valid(ddata->pd_gpio))
- gpio_set_value_cansleep(ddata->pd_gpio, 0);
+ adapter = i2c_get_adapter(i2c_bus_num);
+ if (!adapter) {
+ dev_err(&pdev->dev,
+ "Failed to get I2C adapter, bus %d\n",
+ i2c_bus_num);
+ return -EINVAL;
+ }
- omapdss_dpi_display_disable(dssdev);
+ ddata->i2c_adapter = adapter;
+ }
+
+ return 0;
}
-static int tfp410_probe(struct omap_dss_device *dssdev)
+static int tfp410_probe(struct platform_device *pdev)
{
+ struct tfp410_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ struct omap_dss_device *dssdev;
struct panel_drv_data *ddata;
int r;
- int i2c_bus_num;
- ddata = devm_kzalloc(&dssdev->dev, sizeof(*ddata), GFP_KERNEL);
+ ddata = devm_kzalloc(&pdev->dev, sizeof(*ddata), GFP_KERNEL);
if (!ddata)
return -ENOMEM;
- dssdev->panel.timings = tfp410_default_timings;
+ dev_set_drvdata(&pdev->dev, ddata);
- ddata->dssdev = dssdev;
mutex_init(&ddata->lock);
- if (dssdev->data) {
- struct tfp410_platform_data *pdata = dssdev->data;
-
- ddata->pd_gpio = pdata->power_down_gpio;
- i2c_bus_num = pdata->i2c_bus_num;
- } else {
- ddata->pd_gpio = -1;
- i2c_bus_num = -1;
- }
-
- if (gpio_is_valid(ddata->pd_gpio)) {
- r = devm_gpio_request_one(&dssdev->dev, ddata->pd_gpio,
- GPIOF_OUT_INIT_LOW, "tfp410 pd");
- if (r) {
- dev_err(&dssdev->dev, "Failed to request PD GPIO %d\n",
- ddata->pd_gpio);
+ if (pdata) {
+ r = tfp410_probe_pdata(pdev);
+
[PATCH 07/26] OMAPDSS: add panel list
We currently use the omapdss bus (which contains all the available
displays) to iterate the displays. As the omapdss bus is on its way out,
this needs to be changed.
Instead of using the dss bus to iterate displays, this patch adds our
own list of displays which we manage. The panels on the dss bus are
automatically added to this new list.
An "alias" field is also added to omap_dss_device. This field is
set to "display%d", the same way as omap_dss_device's dev name is set.
This alias is later used to keep backward compatibility, when the
embedded dev is no longer used.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/core.c|2 ++
drivers/video/omap2/dss/display.c | 30 ++
drivers/video/omap2/dss/dss.h |3 +++
include/video/omapdss.h |5 +
4 files changed, 40 insertions(+)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index a9bab9f..5bdd442 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -428,6 +428,7 @@ struct omap_dss_device *dss_alloc_and_init_device(struct
device *parent)
int dss_add_device(struct omap_dss_device *dssdev)
{
+ dss_add_panel(dssdev);
return device_add(&dssdev->dev);
}
@@ -439,6 +440,7 @@ void dss_put_device(struct omap_dss_device *dssdev)
void dss_unregister_device(struct omap_dss_device *dssdev)
{
device_unregister(&dssdev->dev);
+ dss_remove_panel(dssdev);
}
static int dss_unregister_dss_dev(struct device *dev, void *data)
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 0aa8ad8..e785694 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -146,6 +146,36 @@ void dss_disable_all_devices(void)
bus_for_each_dev(bus, NULL, NULL, dss_disable_device);
}
+static LIST_HEAD(panel_list);
+static DEFINE_MUTEX(panel_list_mutex);
+static int disp_num_counter;
+
+int dss_add_panel(struct omap_dss_device *dssdev)
+{
+ struct omap_dss_driver *drv = dssdev->driver;
+
+ snprintf(dssdev->alias, sizeof(dssdev->alias),
+ "display%d", disp_num_counter++);
+
+ if (drv && drv->get_resolution == NULL)
+ drv->get_resolution = omapdss_default_get_resolution;
+ if (drv && drv->get_recommended_bpp == NULL)
+ drv->get_recommended_bpp = omapdss_default_get_recommended_bpp;
+ if (drv && drv->get_timings == NULL)
+ drv->get_timings = omapdss_default_get_timings;
+
+ mutex_lock(&panel_list_mutex);
+ list_add_tail(&dssdev->panel_list, &panel_list);
+ mutex_unlock(&panel_list_mutex);
+ return 0;
+}
+
+void dss_remove_panel(struct omap_dss_device *dssdev)
+{
+ mutex_lock(&panel_list_mutex);
+ list_del(&dssdev->panel_list);
+ mutex_unlock(&panel_list_mutex);
+}
void omap_dss_get_device(struct omap_dss_device *dssdev)
{
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index faaf358..5252423 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -489,4 +489,7 @@ static inline void dss_collect_irq_stats(u32 irqstatus,
unsigned *irq_arr)
}
#endif
+int dss_add_panel(struct omap_dss_device *dssdev);
+void dss_remove_panel(struct omap_dss_device *dssdev);
+
#endif
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 7fe6144..ab4ea37 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -596,6 +596,11 @@ struct omap_dss_output {
struct omap_dss_device {
struct device dev;
+ struct list_head panel_list;
+
+ /* alias in the form of "display%d" */
+ char alias[16];
+
enum omap_display_type type;
/* obsolete, to be removed */
--
1.7.10.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 19/26] OMAPDSS: HDMI: convert to platform device
Convert HDMI driver from omap_dss_driver to a platform driver. The
driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/hdmi_panel.c | 48 +++---
1 file changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index dfb8eda..bc4dea3 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -26,10 +26,13 @@
#include
#include
#include
+#include
#include "dss.h"
static struct {
+ struct omap_dss_device dssdev;
+
/* This protects the panel ops, mainly when accessing the HDMI IP. */
struct mutex lock;
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
@@ -38,8 +41,9 @@ static struct {
#endif
} hdmi;
+static struct omap_dss_driver hdmi_driver;
-static int hdmi_panel_probe(struct omap_dss_device *dssdev)
+static int hdmi_panel_probe(struct platform_device *pdev)
{
/* Initialize default timings to VGA in DVI mode */
const struct omap_video_timings default_timings = {
@@ -59,9 +63,22 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
.interlace = false,
};
+ struct omap_dss_hdmi_data *pdata = dev_get_platdata(&pdev->dev);
+ struct omap_dss_device *dssdev = &hdmi.dssdev;
+ int r;
+
DSSDBG("ENTER hdmi_panel_probe\n");
dssdev->panel.timings = default_timings;
+ dssdev->driver = &hdmi_driver;
+ dssdev->name = "hdmi";
+ dssdev->panel_dev = &pdev->dev;
+
+ /*
+* XXX for now, the hdmi panel's platform data contains the gpios for
+* the tpd level shifter chip, so we pass this data to the hdmi driver.
+*/
+ dssdev->data = pdata;
DSSDBG("hdmi_panel_probe x_res= %d y_res = %d\n",
dssdev->panel.timings.x_res,
@@ -69,12 +86,19 @@ static int hdmi_panel_probe(struct omap_dss_device *dssdev)
omapdss_hdmi_display_set_timing(dssdev, &dssdev->panel.timings);
+ r = omap_hdmi_register_panel(dssdev);
+ if (r) {
+ DSSERR("Failed to register panel\n");
+ return r;
+ }
+
return 0;
}
-static void hdmi_panel_remove(struct omap_dss_device *dssdev)
+static int hdmi_panel_remove(struct platform_device *pdev)
{
-
+ omap_hdmi_free_panel(&hdmi.dssdev);
+ return 0;
}
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
@@ -375,8 +399,6 @@ err:
}
static struct omap_dss_driver hdmi_driver = {
- .probe = hdmi_panel_probe,
- .remove = hdmi_panel_remove,
.enable = hdmi_panel_enable,
.disable= hdmi_panel_disable,
.get_timings= hdmi_get_timings,
@@ -384,15 +406,21 @@ static struct omap_dss_driver hdmi_driver = {
.check_timings = hdmi_check_timings,
.read_edid = hdmi_read_edid,
.detect = hdmi_detect,
+ .get_resolution = omapdss_default_get_resolution,
.audio_enable = hdmi_panel_audio_enable,
.audio_disable = hdmi_panel_audio_disable,
.audio_start= hdmi_panel_audio_start,
.audio_stop = hdmi_panel_audio_stop,
.audio_supported= hdmi_panel_audio_supported,
.audio_config = hdmi_panel_audio_config,
- .driver = {
- .name = "hdmi_panel",
- .owner = THIS_MODULE,
+};
+
+static struct platform_driver hdmi_panel_platform_driver = {
+ .probe = hdmi_panel_probe,
+ .remove = hdmi_panel_remove,
+ .driver = {
+ .name = "hdmi_panel",
+ .owner = THIS_MODULE,
},
};
@@ -404,11 +432,11 @@ int hdmi_panel_init(void)
spin_lock_init(&hdmi.audio_lock);
#endif
- return omap_dss_register_driver(&hdmi_driver);
+ return platform_driver_register(&hdmi_panel_platform_driver);
}
void hdmi_panel_exit(void)
{
- omap_dss_unregister_driver(&hdmi_driver);
+ platform_driver_unregister(&hdmi_panel_platform_driver);
}
--
1.7.10.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 24/26] ARM: OMAP: 4430SDP: use new Taal driver
Change 4430SDP to use the new Taal platform driver instead of the old
omap_dss_driver.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/dss-common.c | 41 --
1 file changed, 17 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 64ca888..a10c56b 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -107,7 +107,8 @@ void __init omap4_panda_display_init_of(void)
#define DLP_POWER_ON_GPIO 40
static struct nokia_dsi_panel_data dsi1_panel = {
- .name = "taal",
+ .name = "lcd",
+ .source = "dsi.0",
.reset_gpio = 102,
.use_ext_te = false,
.ext_te_gpio= 101,
@@ -118,19 +119,15 @@ static struct nokia_dsi_panel_data dsi1_panel = {
},
};
-static struct omap_dss_device sdp4430_lcd_device = {
- .name = "lcd",
- .driver_name= "taal",
- .type = OMAP_DISPLAY_TYPE_DSI,
- .data = &dsi1_panel,
- .phy.dsi= {
- .module = 0,
- },
- .channel= OMAP_DSS_CHANNEL_LCD,
+static struct platform_device sdp4430_lcd1_device = {
+ .name = "taal",
+ .id = 0,
+ .dev.platform_data = &dsi1_panel,
};
static struct nokia_dsi_panel_data dsi2_panel = {
- .name = "taal",
+ .name = "lcd2",
+ .source = "dsi.1",
.reset_gpio = 104,
.use_ext_te = false,
.ext_te_gpio= 103,
@@ -141,16 +138,10 @@ static struct nokia_dsi_panel_data dsi2_panel = {
},
};
-static struct omap_dss_device sdp4430_lcd2_device = {
- .name = "lcd2",
- .driver_name= "taal",
- .type = OMAP_DISPLAY_TYPE_DSI,
- .data = &dsi2_panel,
- .phy.dsi= {
-
- .module = 1,
- },
- .channel= OMAP_DSS_CHANNEL_LCD2,
+static struct platform_device sdp4430_lcd2_device = {
+ .name = "taal",
+ .id = 1,
+ .dev.platform_data = &dsi2_panel,
};
static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
@@ -214,15 +205,13 @@ static struct omap_dss_device sdp4430_picodlp_device = {
};
static struct omap_dss_device *sdp4430_dss_devices[] = {
- &sdp4430_lcd_device,
- &sdp4430_lcd2_device,
&sdp4430_picodlp_device,
};
static struct omap_dss_board_info sdp4430_dss_data = {
.num_devices= ARRAY_SIZE(sdp4430_dss_devices),
.devices= sdp4430_dss_devices,
- .default_device = &sdp4430_lcd_device,
+ .default_display_name = "lcd",
};
void __init omap_4430sdp_display_init(void)
@@ -238,6 +227,8 @@ void __init omap_4430sdp_display_init(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
platform_device_register(&sdp4430_hdmi_device);
+ platform_device_register(&sdp4430_lcd1_device);
+ platform_device_register(&sdp4430_lcd2_device);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
* later have external pull up on the HDMI I2C lines
@@ -265,4 +256,6 @@ void __init omap_4430sdp_display_init_of(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
platform_device_register(&sdp4430_hdmi_device);
+ platform_device_register(&sdp4430_lcd1_device);
+ platform_device_register(&sdp4430_lcd2_device);
}
--
1.7.10.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 25/26] ARM: OMAP: Overo: use new TFP410 platform driver
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/board-overo.c | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index 86bab51..e3cd2bd 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -157,6 +157,20 @@ static struct gpio overo_dss_gpios[] __initdata = {
{ OVERO_GPIO_LCD_BL, GPIOF_OUT_INIT_HIGH, "OVERO_GPIO_LCD_BL" },
};
+static struct tfp410_platform_data dvi_panel = {
+ .name = "dvi",
+ .source = "dpi.0",
+ .data_lines = 24,
+ .i2c_bus_num= 3,
+ .power_down_gpio= -1,
+};
+
+static struct platform_device overo_dvi_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &dvi_panel,
+};
+
static void __init overo_display_init(void)
{
if (gpio_request_array(overo_dss_gpios, ARRAY_SIZE(overo_dss_gpios))) {
@@ -166,20 +180,9 @@ static void __init overo_display_init(void)
gpio_export(OVERO_GPIO_LCD_EN, 0);
gpio_export(OVERO_GPIO_LCD_BL, 0);
-}
-static struct tfp410_platform_data dvi_panel = {
- .i2c_bus_num= 3,
- .power_down_gpio= -1,
-};
-
-static struct omap_dss_device overo_dvi_device = {
- .name = "dvi",
- .type = OMAP_DISPLAY_TYPE_DPI,
- .driver_name= "tfp410",
- .data = &dvi_panel,
- .phy.dpi.data_lines = 24,
-};
+ platform_device_register(&overo_dvi_device);
+}
static struct omap_dss_device overo_tv_device = {
.name = "tv",
@@ -235,7 +238,6 @@ static struct omap_dss_device overo_lcd35_device = {
#endif
static struct omap_dss_device *overo_dss_devices[] = {
- &overo_dvi_device,
&overo_tv_device,
#if defined(CONFIG_PANEL_LGPHILIPS_LB035Q02) || \
defined(CONFIG_PANEL_LGPHILIPS_LB035Q02_MODULE)
@@ -247,7 +249,7 @@ static struct omap_dss_device *overo_dss_devices[] = {
static struct omap_dss_board_info overo_dss_data = {
.num_devices= ARRAY_SIZE(overo_dss_devices),
.devices= overo_dss_devices,
- .default_device = &overo_dvi_device,
+ .default_display_name = "dvi",
};
static struct mtd_partition overo_nand_partitions[] = {
--
1.7.10.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 23/26] ARM: OMAP: Panda & SDP: use new HDMI driver
Change Pandaboard and 4430SDP to use the new HDMI platform driver
instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/dss-common.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 0e94df8..64ca888 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -63,21 +63,13 @@ static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
.hpd_gpio = HDMI_GPIO_HPD,
};
-static struct omap_dss_device omap4_panda_hdmi_device = {
- .name = "hdmi",
- .driver_name = "hdmi_panel",
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = &omap4_panda_hdmi_data,
-};
-
-static struct omap_dss_device *omap4_panda_dss_devices[] = {
- &omap4_panda_hdmi_device,
+static struct platform_device omap4_panda_hdmi_device = {
+ .name = "hdmi_panel",
+ .id = 0,
+ .dev.platform_data = &omap4_panda_hdmi_data,
};
static struct omap_dss_board_info omap4_panda_dss_data = {
- .num_devices= ARRAY_SIZE(omap4_panda_dss_devices),
- .devices= omap4_panda_dss_devices,
.default_display_name = "dvi",
};
@@ -85,6 +77,7 @@ void __init omap4_panda_display_init(void)
{
omap_display_init(&omap4_panda_dss_data);
platform_device_register(&omap4_panda_tfp410_device);
+ platform_device_register(&omap4_panda_hdmi_device);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -104,6 +97,7 @@ void __init omap4_panda_display_init_of(void)
{
omap_display_init(&omap4_panda_dss_data);
platform_device_register(&omap4_panda_tfp410_device);
+ platform_device_register(&omap4_panda_hdmi_device);
}
@@ -165,12 +159,10 @@ static struct omap_dss_hdmi_data sdp4430_hdmi_data = {
.hpd_gpio = HDMI_GPIO_HPD,
};
-static struct omap_dss_device sdp4430_hdmi_device = {
- .name = "hdmi",
- .driver_name = "hdmi_panel",
- .type = OMAP_DISPLAY_TYPE_HDMI,
- .channel = OMAP_DSS_CHANNEL_DIGIT,
- .data = &sdp4430_hdmi_data,
+static struct platform_device sdp4430_hdmi_device = {
+ .name = "hdmi_panel",
+ .id = 0,
+ .dev.platform_data = &sdp4430_hdmi_data,
};
static struct picodlp_panel_data sdp4430_picodlp_pdata = {
@@ -224,7 +216,6 @@ static struct omap_dss_device sdp4430_picodlp_device = {
static struct omap_dss_device *sdp4430_dss_devices[] = {
&sdp4430_lcd_device,
&sdp4430_lcd2_device,
- &sdp4430_hdmi_device,
&sdp4430_picodlp_device,
};
@@ -246,6 +237,7 @@ void __init omap_4430sdp_display_init(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
+ platform_device_register(&sdp4430_hdmi_device);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
* later have external pull up on the HDMI I2C lines
@@ -272,4 +264,5 @@ void __init omap_4430sdp_display_init_of(void)
sdp4430_picodlp_init();
omap_display_init(&sdp4430_dss_data);
+ platform_device_register(&sdp4430_hdmi_device);
}
--
1.7.10.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 22/26] ARM: OMAP: Panda: use new TFP410 platform driver
Use the new TFP410 platform driver instead of the old omap_dss_driver.
Signed-off-by: Tomi Valkeinen
---
arch/arm/mach-omap2/dss-common.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
index 4be5cfc..0e94df8 100644
--- a/arch/arm/mach-omap2/dss-common.c
+++ b/arch/arm/mach-omap2/dss-common.c
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
@@ -42,20 +43,18 @@
/* Display DVI */
#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-/* Using generic display panel */
-static struct tfp410_platform_data omap4_dvi_panel = {
+static struct tfp410_platform_data omap4_tfp410_pdata = {
+ .name = "dvi",
+ .source = "dpi.0",
.i2c_bus_num= 3,
+ .data_lines = 24,
.power_down_gpio= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
};
-static struct omap_dss_device omap4_panda_dvi_device = {
- .type = OMAP_DISPLAY_TYPE_DPI,
- .name = "dvi",
- .driver_name= "tfp410",
- .data = &omap4_dvi_panel,
- .phy.dpi.data_lines = 24,
- .reset_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
- .channel= OMAP_DSS_CHANNEL_LCD2,
+static struct platform_device omap4_panda_tfp410_device = {
+ .name = "tfp410",
+ .id = 0,
+ .dev.platform_data = &omap4_tfp410_pdata,
};
static struct omap_dss_hdmi_data omap4_panda_hdmi_data = {
@@ -73,19 +72,19 @@ static struct omap_dss_device omap4_panda_hdmi_device = {
};
static struct omap_dss_device *omap4_panda_dss_devices[] = {
- &omap4_panda_dvi_device,
&omap4_panda_hdmi_device,
};
static struct omap_dss_board_info omap4_panda_dss_data = {
.num_devices= ARRAY_SIZE(omap4_panda_dss_devices),
.devices= omap4_panda_dss_devices,
- .default_device = &omap4_panda_dvi_device,
+ .default_display_name = "dvi",
};
void __init omap4_panda_display_init(void)
{
omap_display_init(&omap4_panda_dss_data);
+ platform_device_register(&omap4_panda_tfp410_device);
/*
* OMAP4460SDP/Blaze and OMAP4430 ES2.3 SDP/Blaze boards and
@@ -104,6 +103,7 @@ void __init omap4_panda_display_init(void)
void __init omap4_panda_display_init_of(void)
{
omap_display_init(&omap4_panda_dss_data);
+ platform_device_register(&omap4_panda_tfp410_device);
}
--
1.7.10.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 21/26] OMAPDSS: Taal: convert to platform device
Convert Taal driver from omap_dss_driver to a platform driver. The
driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/panel-taal.c | 294 +
1 file changed, 173 insertions(+), 121 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 2fc923d..01de2a9 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -55,6 +56,9 @@ static int _taal_enable_te(struct omap_dss_device *dssdev,
bool enable);
static int taal_panel_reset(struct omap_dss_device *dssdev);
struct taal_data {
+ struct omap_dss_device dssdev;
+ struct platform_device *pdev;
+
struct mutex lock;
struct backlight_device *bldev;
@@ -64,7 +68,7 @@ struct taal_data {
*/
unsigned long hw_guard_wait; /* max guard time in jiffies */
- struct omap_dss_device *dssdev;
+ struct omap_dss_output *src;
/* panel HW configuration from DT or platform data */
int reset_gpio;
@@ -99,6 +103,10 @@ struct taal_data {
struct delayed_work ulps_work;
};
+static struct omap_dss_driver taal_driver;
+
+#define to_panel_data(x) container_of(x, struct taal_data, dssdev)
+
static void taal_esd_work(struct work_struct *work);
static void taal_ulps_work(struct work_struct *work);
@@ -123,7 +131,7 @@ static int taal_dcs_read_1(struct taal_data *td, u8
dcs_cmd, u8 *data)
int r;
u8 buf[1];
- r = dsi_vc_dcs_read(td->dssdev, td->channel, dcs_cmd, buf, 1);
+ r = dsi_vc_dcs_read(&td->dssdev, td->channel, dcs_cmd, buf, 1);
if (r < 0)
return r;
@@ -135,7 +143,7 @@ static int taal_dcs_read_1(struct taal_data *td, u8
dcs_cmd, u8 *data)
static int taal_dcs_write_0(struct taal_data *td, u8 dcs_cmd)
{
- return dsi_vc_dcs_write(td->dssdev, td->channel, &dcs_cmd, 1);
+ return dsi_vc_dcs_write(&td->dssdev, td->channel, &dcs_cmd, 1);
}
static int taal_dcs_write_1(struct taal_data *td, u8 dcs_cmd, u8 param)
@@ -143,7 +151,7 @@ static int taal_dcs_write_1(struct taal_data *td, u8
dcs_cmd, u8 param)
u8 buf[2];
buf[0] = dcs_cmd;
buf[1] = param;
- return dsi_vc_dcs_write(td->dssdev, td->channel, buf, 2);
+ return dsi_vc_dcs_write(&td->dssdev, td->channel, buf, 2);
}
static int taal_sleep_in(struct taal_data *td)
@@ -155,7 +163,7 @@ static int taal_sleep_in(struct taal_data *td)
hw_guard_wait(td);
cmd = MIPI_DCS_ENTER_SLEEP_MODE;
- r = dsi_vc_dcs_write_nosync(td->dssdev, td->channel, &cmd, 1);
+ r = dsi_vc_dcs_write_nosync(&td->dssdev, td->channel, &cmd, 1);
if (r)
return r;
@@ -216,7 +224,7 @@ static int taal_set_update_window(struct taal_data *td,
buf[3] = (x2 >> 8) & 0xff;
buf[4] = (x2 >> 0) & 0xff;
- r = dsi_vc_dcs_write_nosync(td->dssdev, td->channel, buf, sizeof(buf));
+ r = dsi_vc_dcs_write_nosync(&td->dssdev, td->channel, buf, sizeof(buf));
if (r)
return r;
@@ -226,18 +234,18 @@ static int taal_set_update_window(struct taal_data *td,
buf[3] = (y2 >> 8) & 0xff;
buf[4] = (y2 >> 0) & 0xff;
- r = dsi_vc_dcs_write_nosync(td->dssdev, td->channel, buf, sizeof(buf));
+ r = dsi_vc_dcs_write_nosync(&td->dssdev, td->channel, buf, sizeof(buf));
if (r)
return r;
- dsi_vc_send_bta_sync(td->dssdev, td->channel);
+ dsi_vc_send_bta_sync(&td->dssdev, td->channel);
return r;
}
static void taal_queue_esd_work(struct omap_dss_device *dssdev)
{
- struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+ struct taal_data *td = to_panel_data(dssdev);
if (td->esd_interval > 0)
queue_delayed_work(td->workqueue, &td->esd_work,
@@ -246,14 +254,14 @@ static void taal_queue_esd_work(struct omap_dss_device
*dssdev)
static void taal_cancel_esd_work(struct omap_dss_device *dssdev)
{
- struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+ struct taal_data *td = to_panel_data(dssdev);
cancel_delayed_work(&td->esd_work);
}
static void taal_queue_ulps_work(struct omap_dss_device *dssdev)
{
- struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+ struct taal_data *td = to_panel_data(dssdev);
if (td->ulps_timeout > 0)
queue_delayed_work(td->workqueue, &td->ulps_work,
@@ -262,14 +270,14 @@ static void taal_queue_ulps_work(struct omap_dss_device
*dssdev)
static void taal_cancel_ulps_work(struct omap_dss_device *dssdev)
{
- struct taal_data *td = dev_get_drvdata(&dssdev->dev);
+ struct taal_data *td = to_panel_data(dssdev);
cancel_delayed_work(&td->ulps_work);
}
static i
[PATCH 20/26] OMAPDSS: Taal platform_data changes
The forthcoming omap_dss_device to platform_device conversion requires a
few new fields to the Taal platform data. Add the platform data fields
here so that we can make the board file changes independently of the
panel driver changes.
Signed-off-by: Tomi Valkeinen
---
include/video/omap-panel-nokia-dsi.h |1 +
1 file changed, 1 insertion(+)
diff --git a/include/video/omap-panel-nokia-dsi.h
b/include/video/omap-panel-nokia-dsi.h
index 04219a2..8892da7 100644
--- a/include/video/omap-panel-nokia-dsi.h
+++ b/include/video/omap-panel-nokia-dsi.h
@@ -15,6 +15,7 @@ struct omap_dss_device;
*/
struct nokia_dsi_panel_data {
const char *name;
+ const char *source;
int reset_gpio;
--
1.7.10.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 17/26] OMAPDSS: generic-dpi-panel platform_data changes
The forthcoming omap_dss_device to platform_device conversion requires a
few new fields to the generic-dpi-panel platform data. Add the platform
data fields here so that we can make the board file changes
independently of the panel driver changes.
Signed-off-by: Tomi Valkeinen
---
include/video/omap-panel-generic-dpi.h |3 +++
1 file changed, 3 insertions(+)
diff --git a/include/video/omap-panel-generic-dpi.h
b/include/video/omap-panel-generic-dpi.h
index 127e3f2..4ef4419 100644
--- a/include/video/omap-panel-generic-dpi.h
+++ b/include/video/omap-panel-generic-dpi.h
@@ -29,9 +29,12 @@ struct omap_dss_device;
* @platform_disable: platform specific panel disable function
*/
struct panel_generic_dpi_data {
+ const char *display_name;
+ const char *source;
const char *name;
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
+ int data_lines;
};
#endif /* __OMAP_PANEL_GENERIC_DPI_H */
--
1.7.10.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 18/26] OMAPDSS: panel-generic-dpi: convert to platform device
Convert panel-generic-dpi driver from omap_dss_driver to a platform
driver. The driver uses the new panel support from omapdss.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/displays/panel-generic-dpi.c | 141 ++
1 file changed, 91 insertions(+), 50 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index c904f42..cc49c48 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -33,10 +33,14 @@
#include
#include
#include
+#include
#include
#include
+static struct omap_dss_driver generic_dpi_panel_driver;
+#define to_drv_data(x) container_of(x, struct panel_drv_data, dssdev)
+
struct panel_config {
struct omap_video_timings timings;
@@ -517,12 +521,16 @@ static struct panel_config generic_dpi_panels[] = {
};
struct panel_drv_data {
+ struct omap_dss_device dssdev;
- struct omap_dss_device *dssdev;
-
- struct panel_config *panel_config;
+ const struct panel_config *panel_config;
struct mutex lock;
+
+ const struct panel_generic_dpi_data *pdata;
+
+ const char *name;
+ int data_lines;
};
static inline struct panel_generic_dpi_data
@@ -534,9 +542,9 @@ static inline struct panel_generic_dpi_data
static int generic_dpi_panel_power_on(struct omap_dss_device *dssdev)
{
int r;
- struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
- struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
- struct panel_config *panel_config = drv_data->panel_config;
+ struct panel_drv_data *drv_data = to_drv_data(dssdev);
+ const struct panel_config *panel_config = drv_data->panel_config;
+ const struct panel_generic_dpi_data *pdata = drv_data->pdata;
if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
return 0;
@@ -552,8 +560,8 @@ static int generic_dpi_panel_power_on(struct
omap_dss_device *dssdev)
if (panel_config->power_on_delay)
msleep(panel_config->power_on_delay);
- if (panel_data->platform_enable) {
- r = panel_data->platform_enable(dssdev);
+ if (pdata && pdata->platform_enable) {
+ r = pdata->platform_enable(dssdev);
if (r)
goto err1;
}
@@ -567,15 +575,15 @@ err0:
static void generic_dpi_panel_power_off(struct omap_dss_device *dssdev)
{
- struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
- struct panel_drv_data *drv_data = dev_get_drvdata(&dssdev->dev);
- struct panel_config *panel_config = drv_data->panel_config;
+ struct panel_drv_data *drv_data = to_drv_data(dssdev);
+ const struct panel_config *panel_config = drv_data->panel_config;
+ const struct panel_generic_dpi_data *pdata = drv_data->pdata;
if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE)
return;
- if (panel_data->platform_disable)
- panel_data->platform_disable(dssdev);
+ if (pdata && pdata->platform_disable)
+ pdata->platform_disable(dssdev);
/* wait couple of vsyncs after disabling the LCD */
if (panel_config->power_off_delay)
@@ -584,20 +592,16 @@ static void generic_dpi_panel_power_off(struct
omap_dss_device *dssdev)
omapdss_dpi_display_disable(dssdev);
}
-static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
+static int generic_dpi_panel_probe_pdata(struct platform_device *pdev)
{
- struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
+ const struct panel_generic_dpi_data *pdata =
+ dev_get_platdata(&pdev->dev);
+ struct panel_drv_data *drv_data = dev_get_drvdata(&pdev->dev);
struct panel_config *panel_config = NULL;
- struct panel_drv_data *drv_data = NULL;
int i;
- dev_dbg(&dssdev->dev, "probe\n");
-
- if (!panel_data || !panel_data->name)
- return -EINVAL;
-
for (i = 0; i < ARRAY_SIZE(generic_dpi_panels); i++) {
- if (strcmp(panel_data->name, generic_dpi_panels[i].name) == 0) {
+ if (strcmp(pdata->name, generic_dpi_panels[i].name) == 0) {
panel_config = &generic_dpi_panels[i];
break;
}
@@ -606,36 +610,70 @@ static int generic_dpi_panel_probe(struct omap_dss_device
*dssdev)
if (!panel_config)
return -EINVAL;
- dssdev->panel.timings = panel_config->timings;
+ drv_data->panel_config = panel_config;
+ drv_data->pdata = pdata;
+ drv_data->name = pdata->display_name;
+ drv_data->data_lines = pdata->data_lines;
- drv_data = kzalloc(sizeof(*drv_data), GFP_KERNEL);
+ return 0;
+}
+
+static int generic_dpi_panel_probe(struct platform_device *pdev)
+{
+ struct panel_drv_data *d
[PATCH 12/26] OMAPDSS: DPI: new panel registration
This patch adds new way to register DPI panels. This new method will be
used by the panel drivers that are converted away from the current dss
bus based model.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 35 ++-
include/video/omapdss.h |2 ++
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 08342d1..e7beea2 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -575,7 +575,7 @@ static enum omap_channel dpi_get_channel(void)
}
}
-static int __init dpi_init_display(struct omap_dss_device *dssdev)
+static int dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev;
@@ -615,6 +615,39 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
return 0;
}
+int omap_dpi_register_panel(struct omap_dss_device *dssdev)
+{
+ int r;
+
+ dssdev->type = OMAP_DISPLAY_TYPE_DPI;
+
+ r = dpi_init_display(dssdev);
+ if (r) {
+ DSSERR("device %s init failed: %d\n", dssdev->name, r);
+ return r;
+ }
+
+ r = omapdss_output_set_device(&dpi.output, dssdev);
+ if (r) {
+ DSSERR("failed to connect output to new device: %s\n",
+ dssdev->name);
+ return r;
+ }
+
+ dss_add_panel(dssdev);
+
+ return 0;
+}
+EXPORT_SYMBOL(omap_dpi_register_panel);
+
+void omap_dpi_free_panel(struct omap_dss_device *dssdev)
+{
+ dss_remove_panel(dssdev);
+
+ omapdss_output_unset_device(&dpi.output);
+}
+EXPORT_SYMBOL(omap_dpi_free_panel);
+
static struct omap_dss_device * __init dpi_find_dssdev(struct platform_device
*pdev)
{
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ab36ee3..78c4e51 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -863,6 +863,8 @@ int omapdss_dsi_display_enable(struct omap_dss_device
*dssdev);
void omapdss_dsi_display_disable(struct omap_dss_device *dssdev,
bool disconnect_lanes, bool enter_ulps);
+int omap_dpi_register_panel(struct omap_dss_device *dssdev);
+void omap_dpi_free_panel(struct omap_dss_device *dssdev);
int omapdss_dpi_display_enable(struct omap_dss_device *dssdev);
void omapdss_dpi_display_disable(struct omap_dss_device *dssdev);
void omapdss_dpi_set_timings(struct omap_dss_device *dssdev,
--
1.7.10.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 15/26] OMAPDSS: TFP410 platform_data changes
The forthcoming omap_dss_device to platform_device conversion requires a
few new fields to the TFP410 platform data. Add the platform data fields
here so that we can make the board file changes independently of the
panel driver changes.
Signed-off-by: Tomi Valkeinen
---
include/video/omap-panel-tfp410.h |5 +
1 file changed, 5 insertions(+)
diff --git a/include/video/omap-panel-tfp410.h
b/include/video/omap-panel-tfp410.h
index aef35e4..cb37c87 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -24,12 +24,17 @@ struct omap_dss_device;
/**
* struct tfp410_platform_data - panel driver configuration data
+ * @name: name for this output
+ * @source: name for the video source
* @i2c_bus_num: i2c bus id for the panel
* @power_down_gpio: gpio number for PD pin (or -1 if not available)
*/
struct tfp410_platform_data {
+ const char *name;
+ const char *source;
int i2c_bus_num;
int power_down_gpio;
+ int data_lines;
};
#endif /* __OMAP_PANEL_TFP410_H */
--
1.7.10.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 14/26] OMAPDSS: HDMI: new panel registration
This patch adds new way to register HDMI panels. This new method will be
used by the panel drivers that are converted away from the current dss
bus based model.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss.h |2 ++
drivers/video/omap2/dss/hdmi.c | 41 +++-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index d603a40..eb1e325 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -450,6 +450,8 @@ static inline unsigned long hdmi_get_pixel_clock(void)
return 0;
}
#endif
+int omap_hdmi_register_panel(struct omap_dss_device *dssdev);
+void omap_hdmi_free_panel(struct omap_dss_device *dssdev);
int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev);
void omapdss_hdmi_display_disable(struct omap_dss_device *dssdev);
int omapdss_hdmi_core_enable(struct omap_dss_device *dssdev);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 4b32dd3..f9e38c4 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -328,7 +328,7 @@ static void hdmi_runtime_put(void)
WARN_ON(r < 0 && r != -ENOSYS);
}
-static int __init hdmi_init_display(struct omap_dss_device *dssdev)
+static int hdmi_init_display(struct omap_dss_device *dssdev)
{
int r;
@@ -960,6 +960,45 @@ int hdmi_audio_config(struct omap_dss_audio *audio)
#endif
+int omap_hdmi_register_panel(struct omap_dss_device *dssdev)
+{
+ struct omap_dss_hdmi_data *priv = dssdev->data;
+ int r;
+
+ dssdev->type = OMAP_DISPLAY_TYPE_HDMI;
+
+ hdmi.ct_cp_hpd_gpio = priv->ct_cp_hpd_gpio;
+ hdmi.ls_oe_gpio = priv->ls_oe_gpio;
+ hdmi.hpd_gpio = priv->hpd_gpio;
+
+ r = hdmi_init_display(dssdev);
+ if (r) {
+ DSSERR("device %s init failed: %d\n", dssdev->name, r);
+ return r;
+ }
+
+ r = omapdss_output_set_device(&hdmi.output, dssdev);
+ if (r) {
+ DSSERR("failed to connect output to new device: %s\n",
+ dssdev->name);
+ hdmi_uninit_display(dssdev);
+ return r;
+ }
+
+ dss_add_panel(dssdev);
+
+ return 0;
+}
+EXPORT_SYMBOL(omap_hdmi_register_panel);
+
+void omap_hdmi_free_panel(struct omap_dss_device *dssdev)
+{
+ hdmi_uninit_display(dssdev);
+ omapdss_output_unset_device(&hdmi.output);
+ dss_remove_panel(dssdev);
+}
+EXPORT_SYMBOL(omap_hdmi_free_panel);
+
static struct omap_dss_device * __init hdmi_find_dssdev(struct platform_device
*pdev)
{
struct omap_dss_board_info *pdata = pdev->dev.platform_data;
--
1.7.10.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 13/26] OMAPDSS: DSI: new panel registration
This patch adds new way to register DSI panels. This new method will be
used by the panel drivers that are converted away from the current dss
bus based model.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dsi.c | 55 -
include/video/omapdss.h |3 +++
2 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index ddb8bf6..fb77aa8 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5225,7 +5225,7 @@ static enum omap_channel dsi_get_channel(int module_id)
}
}
-static int __init dsi_init_display(struct omap_dss_device *dssdev)
+static int dsi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev =
dsi_get_dsidev_from_id(dssdev->phy.dsi.module);
@@ -5253,6 +5253,59 @@ static int __init dsi_init_display(struct
omap_dss_device *dssdev)
return 0;
}
+int omap_dsi_register_panel(struct omap_dss_device *dssdev,
+ struct omap_dss_output *out)
+{
+ int r;
+ struct platform_device *dsidev;
+ struct dsi_data *dsi;
+
+ dssdev->type = OMAP_DISPLAY_TYPE_DSI;
+
+ switch (out->id) {
+ case OMAP_DSS_OUTPUT_DSI1:
+ dssdev->phy.dsi.module = 0;
+ break;
+ case OMAP_DSS_OUTPUT_DSI2:
+ dssdev->phy.dsi.module = 1;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ dsidev = dsi_get_dsidev_from_id(dssdev->phy.dsi.module);
+ dsi = dsi_get_dsidrv_data(dsidev);
+
+ r = dsi_init_display(dssdev);
+ if (r) {
+ DSSERR("device %s init failed: %d\n", dssdev->name, r);
+ return r;
+ }
+
+ r = omapdss_output_set_device(&dsi->output, dssdev);
+ if (r) {
+ DSSERR("failed to connect output to new device: %s\n",
+ dssdev->name);
+ return r;
+ }
+
+ dss_add_panel(dssdev);
+
+ return 0;
+}
+EXPORT_SYMBOL(omap_dsi_register_panel);
+
+void omap_dsi_free_panel(struct omap_dss_device *dssdev)
+{
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+ dss_remove_panel(dssdev);
+
+ omapdss_output_unset_device(&dsi->output);
+}
+EXPORT_SYMBOL(omap_dsi_free_panel);
+
int omap_dsi_request_vc(struct omap_dss_device *dssdev, int *channel)
{
struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 78c4e51..2bf90fd 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -862,6 +862,9 @@ int omapdss_dsi_configure_pins(struct omap_dss_device
*dssdev,
int omapdss_dsi_display_enable(struct omap_dss_device *dssdev);
void omapdss_dsi_display_disable(struct omap_dss_device *dssdev,
bool disconnect_lanes, bool enter_ulps);
+int omap_dsi_register_panel(struct omap_dss_device *dssdev,
+ struct omap_dss_output *out);
+void omap_dsi_free_panel(struct omap_dss_device *dssdev);
int omap_dpi_register_panel(struct omap_dss_device *dssdev);
void omap_dpi_free_panel(struct omap_dss_device *dssdev);
--
1.7.10.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 11/26] OMAPDSS: Add panel_dev pointer to dssdev
We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded "dev" struct needs to be removed from omap_dss_device.
After we've finished the removal of the dss bus, we see the following
changes:
- struct omap_dss_device won't be a real Linux device anymore, but more
like a "display entity".
- struct omap_dss_driver won't be a Linux device driver, but "display
entity ops".
- The panel devices/drivers won't be omapdss devices/drivers, but
platform/i2c/spi/etc devices/drivers, whichever fits the control
mechanism of the panel.
- The panel drivers will create omap_dss_device and omap_dss_driver,
fill the required fields, and register the omap_dss_device to
omapdss.
- omap_dss_device won't have an embedded dev struct anymore, but a
dev pointer to the actual device that manages the omap_dss_device.
The model described above resembles the model that has been discussed
with CDF (common display framework).
For the duration of the conversion, we temporarily have two devs in the
dssdev, the old "dev", which is a full embedded device struct, and the
new "panel_dev", which is a pointer to the device. "dev" will be removed
in the future, and "panel_dev" will be renamed "dev".
For devices belonging to dss bus the panel_dev is initialized to point
to dev. This way all the code can just use the panel_dev, for both old
and new style panels.
Both the new and old style panel drivers work during the conversion, and
only after the dss bus support is removed will the old style panels stop
to compile.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/core.c |2 ++
drivers/video/omap2/dss/display-sysfs.c |7 ---
drivers/video/omap2/dss/display.c |8
include/video/omapdss.h |4
4 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 054e980..5a6ac3b 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -400,6 +400,8 @@ struct omap_dss_device *dss_alloc_and_init_device(struct
device *parent)
int dss_add_device(struct omap_dss_device *dssdev)
{
+ dssdev->panel_dev = &dssdev->dev;
+
dss_add_panel(dssdev);
return device_add(&dssdev->dev);
}
diff --git a/drivers/video/omap2/dss/display-sysfs.c
b/drivers/video/omap2/dss/display-sysfs.c
index 537921b..af90bff 100644
--- a/drivers/video/omap2/dss/display-sysfs.c
+++ b/drivers/video/omap2/dss/display-sysfs.c
@@ -33,7 +33,7 @@ static struct omap_dss_device *to_dss_device_sysfs(struct
device *dev)
struct omap_dss_device *dssdev = NULL;
for_each_dss_dev(dssdev) {
- if (&dssdev->dev == dev) {
+ if (dssdev->panel_dev == dev) {
omap_dss_put_device(dssdev);
return dssdev;
}
@@ -304,7 +304,7 @@ int display_init_sysfs(struct platform_device *pdev)
int r;
for_each_dss_dev(dssdev) {
- struct kobject *kobj = &dssdev->dev.kobj;
+ struct kobject *kobj = &dssdev->panel_dev->kobj;
r = sysfs_create_files(kobj, display_sysfs_attrs);
if (r) {
@@ -335,6 +335,7 @@ void display_uninit_sysfs(struct platform_device *pdev)
for_each_dss_dev(dssdev) {
sysfs_remove_link(&pdev->dev.kobj, dssdev->alias);
- sysfs_remove_files(&dssdev->dev.kobj, display_sysfs_attrs);
+ sysfs_remove_files(&dssdev->panel_dev->kobj,
+ display_sysfs_attrs);
}
}
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 85e1cd3..fbadefe 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -158,13 +158,13 @@ void dss_remove_panel(struct omap_dss_device *dssdev)
void omap_dss_get_device(struct omap_dss_device *dssdev)
{
- get_device(&dssdev->dev);
+ get_device(dssdev->panel_dev);
}
EXPORT_SYMBOL(omap_dss_get_device);
void omap_dss_put_device(struct omap_dss_device *dssdev)
{
- put_device(&dssdev->dev);
+ put_device(dssdev->panel_dev);
}
EXPORT_SYMBOL(omap_dss_put_device);
@@ -243,7 +243,7 @@ int omap_dss_start_device(struct omap_dss_device *dssdev)
return -ENODEV;
}
- if (!try_module_get(dssdev->dev.driver->owner)) {
+ if (!try_module_get(dssdev->panel_dev->driver->owner)) {
return -ENODEV;
}
@@ -253,7 +253,7 @@ EXPORT_SYMBOL(omap_dss_start_device);
void omap_dss_stop_device(struct omap_dss_device *dssdev)
{
- module_put(dssdev->dev.driver->owner);
+ module_put(dssdev->panel_dev->driver->owner);
}
EXPORT_SYMBOL(omap_dss_stop_device);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ab4ea37..ab36ee3 100644
--- a/include/video/omapdss.h
+++ b/include
[PATCH 10/26] OMAPDSS: implement display sysfs without dss bus
We aim to remove the custom omapdss bus totally, as it's quite a strange
construct and won't be compatible with common display framework. One
problem on the road is that we have sysfs files for each display, and
they depend on the omapdss bus.
This patch creates the display sysfs files independent of the omapdss
bus. This gives us backwards compatibility without using the omapdss bus
for the sysfs files.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/apply.c | 15 ++--
drivers/video/omap2/dss/core.c | 28 ---
drivers/video/omap2/dss/display-sysfs.c | 125 ++-
drivers/video/omap2/dss/dss.h |6 +-
4 files changed, 79 insertions(+), 95 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index a4b356a..44f94b8 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -1569,7 +1569,6 @@ static DEFINE_MUTEX(compat_init_lock);
int omapdss_compat_init(void)
{
struct platform_device *pdev = dss_get_core_pdev();
- struct omap_dss_device *dssdev = NULL;
int i, r;
mutex_lock(&compat_init_lock);
@@ -1615,12 +1614,9 @@ int omapdss_compat_init(void)
if (r)
goto err_mgr_ops;
- for_each_dss_dev(dssdev) {
- r = display_init_sysfs(pdev, dssdev);
- /* XXX uninit sysfs files on error */
- if (r)
- goto err_disp_sysfs;
- }
+ r = display_init_sysfs(pdev);
+ if (r)
+ goto err_disp_sysfs;
dispc_runtime_get();
@@ -1637,6 +1633,7 @@ out:
err_init_irq:
dispc_runtime_put();
+ display_uninit_sysfs(pdev);
err_disp_sysfs:
dss_uninstall_mgr_ops();
@@ -1656,7 +1653,6 @@ EXPORT_SYMBOL(omapdss_compat_init);
void omapdss_compat_uninit(void)
{
struct platform_device *pdev = dss_get_core_pdev();
- struct omap_dss_device *dssdev = NULL;
mutex_lock(&compat_init_lock);
@@ -1665,8 +1661,7 @@ void omapdss_compat_uninit(void)
dss_dispc_uninitialize_irq();
- for_each_dss_dev(dssdev)
- display_uninit_sysfs(pdev, dssdev);
+ display_uninit_sysfs(pdev);
dss_uninstall_mgr_ops();
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 5bdd442..054e980 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -287,37 +287,9 @@ static int dss_bus_match(struct device *dev, struct
device_driver *driver)
return strcmp(dssdev->driver_name, driver->name) == 0;
}
-static ssize_t device_name_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
- return snprintf(buf, PAGE_SIZE, "%s\n",
- dssdev->name ?
- dssdev->name : "");
-}
-
-static struct device_attribute default_dev_attrs[] = {
- __ATTR(name, S_IRUGO, device_name_show, NULL),
- __ATTR_NULL,
-};
-
-static ssize_t driver_name_show(struct device_driver *drv, char *buf)
-{
- struct omap_dss_driver *dssdrv = to_dss_driver(drv);
- return snprintf(buf, PAGE_SIZE, "%s\n",
- dssdrv->driver.name ?
- dssdrv->driver.name : "");
-}
-static struct driver_attribute default_drv_attrs[] = {
- __ATTR(name, S_IRUGO, driver_name_show, NULL),
- __ATTR_NULL,
-};
-
static struct bus_type dss_bus_type = {
.name = "omapdss",
.match = dss_bus_match,
- .dev_attrs = default_dev_attrs,
- .drv_attrs = default_drv_attrs,
};
static void dss_bus_release(struct device *dev)
diff --git a/drivers/video/omap2/dss/display-sysfs.c
b/drivers/video/omap2/dss/display-sysfs.c
index 18211a9..537921b 100644
--- a/drivers/video/omap2/dss/display-sysfs.c
+++ b/drivers/video/omap2/dss/display-sysfs.c
@@ -22,17 +22,40 @@
#include
#include
-#include
#include
+#include
#include
#include "dss.h"
-#include "dss_features.h"
+
+static struct omap_dss_device *to_dss_device_sysfs(struct device *dev)
+{
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ if (&dssdev->dev == dev) {
+ omap_dss_put_device(dssdev);
+ return dssdev;
+ }
+ }
+
+ return NULL;
+}
+
+static ssize_t display_name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct omap_dss_device *dssdev = to_dss_device_sysfs(dev);
+
+ return snprintf(buf, PAGE_SIZE, "%s\n",
+ dssdev->name ?
+ dssdev->name : "");
+}
static ssize_t display_enabled_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
- struct omap_dss_device *dssdev = to_dss_device(dev);
+ struct omap_dss_device *dssdev = to_dss_dev
[PATCH 09/26] OMAPDSS: don't use dss bus in suspend/resume
We have support functions to suspend and resume all the displays that
are used with system suspend. These functions use the dss bus to iterate
the display devices.
As we aim to remove the custom dss bus totally, this patch removes the
explicit use of dss bus from these functions. Instead the
for_each_dss_dev() macro is used to go through the devices.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/display.c | 77 ++---
1 file changed, 28 insertions(+), 49 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 50792bf..85e1cd3 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -76,74 +76,53 @@ void omapdss_default_get_timings(struct omap_dss_device
*dssdev,
}
EXPORT_SYMBOL(omapdss_default_get_timings);
-static int dss_suspend_device(struct device *dev, void *data)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
-
- if (dssdev->state != OMAP_DSS_DISPLAY_ACTIVE) {
- dssdev->activate_after_resume = false;
- return 0;
- }
-
- dssdev->driver->disable(dssdev);
-
- dssdev->activate_after_resume = true;
-
- return 0;
-}
-
int dss_suspend_all_devices(void)
{
- int r;
- struct bus_type *bus = dss_get_bus();
-
- r = bus_for_each_dev(bus, NULL, NULL, dss_suspend_device);
- if (r) {
- /* resume all displays that were suspended */
- dss_resume_all_devices();
- return r;
- }
-
- return 0;
-}
+ struct omap_dss_device *dssdev = NULL;
-static int dss_resume_device(struct device *dev, void *data)
-{
- int r;
- struct omap_dss_device *dssdev = to_dss_device(dev);
+ for_each_dss_dev(dssdev) {
+ if (!dssdev->driver)
+ continue;
- if (dssdev->activate_after_resume) {
- r = dssdev->driver->enable(dssdev);
- if (r)
- return r;
+ if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE) {
+ dssdev->driver->disable(dssdev);
+ dssdev->activate_after_resume = true;
+ } else {
+ dssdev->activate_after_resume = false;
+ }
}
- dssdev->activate_after_resume = false;
-
return 0;
}
int dss_resume_all_devices(void)
{
- struct bus_type *bus = dss_get_bus();
-
- return bus_for_each_dev(bus, NULL, NULL, dss_resume_device);
-}
+ struct omap_dss_device *dssdev = NULL;
-static int dss_disable_device(struct device *dev, void *data)
-{
- struct omap_dss_device *dssdev = to_dss_device(dev);
+ for_each_dss_dev(dssdev) {
+ if (!dssdev->driver)
+ continue;
- if (dssdev->state != OMAP_DSS_DISPLAY_DISABLED)
- dssdev->driver->disable(dssdev);
+ if (dssdev->activate_after_resume) {
+ dssdev->driver->enable(dssdev);
+ dssdev->activate_after_resume = false;
+ }
+ }
return 0;
}
void dss_disable_all_devices(void)
{
- struct bus_type *bus = dss_get_bus();
- bus_for_each_dev(bus, NULL, NULL, dss_disable_device);
+ struct omap_dss_device *dssdev = NULL;
+
+ for_each_dss_dev(dssdev) {
+ if (!dssdev->driver)
+ continue;
+
+ if (dssdev->state == OMAP_DSS_DISPLAY_ACTIVE)
+ dssdev->driver->disable(dssdev);
+ }
}
static LIST_HEAD(panel_list);
--
1.7.10.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 08/26] OMAPDSS: use the panel list in omap_dss_get_next_device
omap_dss_get_next_device() uses the dss bus to iterate over the
displays. This patch changes omap_dss_get_next_device() to use the new
panel list instead.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/display.c | 63 +++--
1 file changed, 46 insertions(+), 17 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index e785694..50792bf 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -189,27 +189,51 @@ void omap_dss_put_device(struct omap_dss_device *dssdev)
}
EXPORT_SYMBOL(omap_dss_put_device);
-/* ref count of the found device is incremented. ref count
- * of from-device is decremented. */
+/*
+ * ref count of the found device is incremented.
+ * ref count of from-device is decremented.
+ */
struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from)
{
- struct device *dev;
- struct device *dev_start = NULL;
- struct omap_dss_device *dssdev = NULL;
+ struct list_head *l;
+ struct omap_dss_device *dssdev;
+
+ mutex_lock(&panel_list_mutex);
+
+ if (list_empty(&panel_list)) {
+ dssdev = NULL;
+ goto out;
+ }
- int match(struct device *dev, void *data)
- {
- return 1;
+ if (from == NULL) {
+ dssdev = list_first_entry(&panel_list, struct omap_dss_device,
+ panel_list);
+ omap_dss_get_device(dssdev);
+ goto out;
}
- if (from)
- dev_start = &from->dev;
- dev = bus_find_device(dss_get_bus(), dev_start, NULL, match);
- if (dev)
- dssdev = to_dss_device(dev);
- if (from)
- put_device(&from->dev);
+ omap_dss_put_device(from);
+
+ list_for_each(l, &panel_list) {
+ dssdev = list_entry(l, struct omap_dss_device, panel_list);
+ if (dssdev == from) {
+ if (list_is_last(l, &panel_list)) {
+ dssdev = NULL;
+ goto out;
+ }
+
+ dssdev = list_entry(l->next, struct omap_dss_device,
+ panel_list);
+ omap_dss_get_device(dssdev);
+ goto out;
+ }
+ }
+
+ WARN(1, "'from' dssdev not found\n");
+ dssdev = NULL;
+out:
+ mutex_unlock(&panel_list_mutex);
return dssdev;
}
EXPORT_SYMBOL(omap_dss_get_next_device);
@@ -219,12 +243,17 @@ struct omap_dss_device *omap_dss_find_device(void *data,
{
struct omap_dss_device *dssdev = NULL;
+ mutex_lock(&panel_list_mutex);
+
while ((dssdev = omap_dss_get_next_device(dssdev)) != NULL) {
if (match(dssdev, data))
- return dssdev;
+ goto out;
}
- return NULL;
+ dssdev = NULL;
+out:
+ mutex_unlock(&panel_list_mutex);
+ return dssdev;
}
EXPORT_SYMBOL(omap_dss_find_device);
--
1.7.10.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 05/26] OMAPDSS: DPI: fix regulators
On some platforms DPI requires a regulator to be enabled to power up the
output pins. This regulator is, for some reason, currently attached to
the virtual omapdss device, instead of the DPI device. This does not
work for DT, as the regulator mappings need to be described in the DT
data, and the virtual omapdss device is not present there.
Fix the issue by acquiring the regulator in the DPI device. To retain
compatibility with the current board files, the old method of getting
the regulator is kept. The old method can be removed when the board
files have been changed to pass the regulator to DPI.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index ad67a9c..08342d1 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -37,7 +37,10 @@
#include "dss_features.h"
static struct {
+ struct platform_device *pdev;
+
struct regulator *vdds_dsi_reg;
+ bool vdds_dsi_from_core;
struct platform_device *dsidev;
struct mutex lock;
@@ -583,10 +586,15 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
struct regulator *vdds_dsi;
vdds_dsi = dss_get_vdds_dsi();
-
if (IS_ERR(vdds_dsi)) {
- DSSERR("can't get VDDS_DSI regulator\n");
- return PTR_ERR(vdds_dsi);
+ vdds_dsi = regulator_get(&dpi.pdev->dev, "vdds_dsi");
+ if (IS_ERR(vdds_dsi)) {
+ DSSERR("can't get VDDS_DSI regulator\n");
+ return PTR_ERR(vdds_dsi);
+ }
+ dpi.vdds_dsi_from_core = false;
+ } else {
+ dpi.vdds_dsi_from_core = true;
}
dpi.vdds_dsi_reg = vdds_dsi;
@@ -698,6 +706,8 @@ static void __exit dpi_uninit_output(struct platform_device
*pdev)
static int __init omap_dpi_probe(struct platform_device *pdev)
{
+ dpi.pdev = pdev;
+
mutex_init(&dpi.lock);
dpi_init_output(pdev);
@@ -714,6 +724,11 @@ static int __exit omap_dpi_remove(struct platform_device
*pdev)
dpi_uninit_output(pdev);
+ if (dpi.vdds_dsi_reg != NULL && dpi.vdds_dsi_from_core == false) {
+ regulator_put(dpi.vdds_dsi_reg);
+ dpi.vdds_dsi_reg = NULL;
+ }
+
return 0;
}
--
1.7.10.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 04/26] OMAPDSS: fix dss_get_ctx_loss_count for DT
When using DT, dss device does not have platform data. However,
dss_get_ctx_loss_count() uses dss device's platform data to find the
get_ctx_loss_count function pointer.
To fix this, change dss_get_ctx_loss_count() needs to be changed to get
the platform data from the omapdss device, which is a "virtual" device
and always has platform data.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index fdd32e8..62db201 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -157,7 +157,8 @@ static void dss_restore_context(void)
int dss_get_ctx_loss_count(void)
{
- struct omap_dss_board_info *board_data = dss.pdev->dev.platform_data;
+ struct platform_device *core_pdev = dss_get_core_pdev();
+ struct omap_dss_board_info *board_data = core_pdev->dev.platform_data;
int cnt;
if (!board_data->get_context_loss_count)
--
1.7.10.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 03/26] OMAPDSS: add omap_dss_find_output_by_node()
Add a support function to find a DSS output by given DT node. This is
used in later patches to link the panels to DSS outputs.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/output.c | 13 +
include/video/omapdss.h |1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/video/omap2/dss/output.c b/drivers/video/omap2/dss/output.c
index 3274628..4d01001 100644
--- a/drivers/video/omap2/dss/output.c
+++ b/drivers/video/omap2/dss/output.c
@@ -128,6 +128,19 @@ struct omap_dss_output *omap_dss_find_output(const char
*name)
}
EXPORT_SYMBOL(omap_dss_find_output);
+struct omap_dss_output *omap_dss_find_output_by_node(struct device_node *node)
+{
+ struct omap_dss_output *out;
+
+ list_for_each_entry(out, &output_list, list) {
+ if (out->pdev->dev.of_node == node)
+ return out;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL(omap_dss_find_output_by_node);
+
static const struct dss_mgr_ops *dss_mgr_ops;
int dss_install_mgr_ops(const struct dss_mgr_ops *mgr_ops)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index aad47a2..7fe6144 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -780,6 +780,7 @@ struct omap_overlay *omap_dss_get_overlay(int num);
struct omap_dss_output *omap_dss_get_output(enum omap_dss_output_id id);
struct omap_dss_output *omap_dss_find_output(const char *name);
+struct omap_dss_output *omap_dss_find_output_by_node(struct device_node *node);
int omapdss_output_set_device(struct omap_dss_output *out,
struct omap_dss_device *dssdev);
int omapdss_output_unset_device(struct omap_dss_output *out);
--
1.7.10.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 02/26] OMAPDSS: add omap_dss_find_output()
Add a support function to find a DSS output by given name. This is used
in later patches to link the panels to DSS outputs.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/output.c | 13 +
include/video/omapdss.h |1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/video/omap2/dss/output.c b/drivers/video/omap2/dss/output.c
index 5214df6..3274628 100644
--- a/drivers/video/omap2/dss/output.c
+++ b/drivers/video/omap2/dss/output.c
@@ -115,6 +115,19 @@ struct omap_dss_output *omap_dss_get_output(enum
omap_dss_output_id id)
}
EXPORT_SYMBOL(omap_dss_get_output);
+struct omap_dss_output *omap_dss_find_output(const char *name)
+{
+ struct omap_dss_output *out;
+
+ list_for_each_entry(out, &output_list, list) {
+ if (strcmp(out->name, name) == 0)
+ return out;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL(omap_dss_find_output);
+
static const struct dss_mgr_ops *dss_mgr_ops;
int dss_install_mgr_ops(const struct dss_mgr_ops *mgr_ops)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index d5f1fff..aad47a2 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -779,6 +779,7 @@ int omap_dss_get_num_overlays(void);
struct omap_overlay *omap_dss_get_overlay(int num);
struct omap_dss_output *omap_dss_get_output(enum omap_dss_output_id id);
+struct omap_dss_output *omap_dss_find_output(const char *name);
int omapdss_output_set_device(struct omap_dss_output *out,
struct omap_dss_device *dssdev);
int omapdss_output_unset_device(struct omap_dss_output *out);
--
1.7.10.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 01/26] OMAPDSS: only probe pdata if there's one
omapdss output drivers always read the platform data. This crashes when
there's no platform data when using DT.
Add a check to read the platform data only if it exists.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c |3 ++-
drivers/video/omap2/dss/dsi.c |3 ++-
drivers/video/omap2/dss/hdmi.c |3 ++-
drivers/video/omap2/dss/rfbi.c |3 ++-
drivers/video/omap2/dss/sdi.c |3 ++-
drivers/video/omap2/dss/venc.c |3 ++-
6 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index abe1a4e2..ad67a9c 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -702,7 +702,8 @@ static int __init omap_dpi_probe(struct platform_device
*pdev)
dpi_init_output(pdev);
- dpi_probe_pdata(pdev);
+ if (pdev->dev.platform_data)
+ dpi_probe_pdata(pdev);
return 0;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8db29bf..ddb8bf6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -5573,7 +5573,8 @@ static int __init omap_dsihw_probe(struct platform_device
*dsidev)
dsi_init_output(dsidev);
- dsi_probe_pdata(dsidev);
+ if (dsidev->dev.platform_data)
+ dsi_probe_pdata(dsidev);
dsi_runtime_put(dsidev);
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index a6f9538..4b32dd3 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -1102,7 +1102,8 @@ static int __init omapdss_hdmihw_probe(struct
platform_device *pdev)
dss_debugfs_create_file("hdmi", hdmi_dump_regs);
- hdmi_probe_pdata(pdev);
+ if (pdev->dev.platform_data)
+ hdmi_probe_pdata(pdev);
return 0;
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 1a691bb..946c415 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -1091,7 +1091,8 @@ static int __init omap_rfbihw_probe(struct
platform_device *pdev)
rfbi_init_output(pdev);
- rfbi_probe_pdata(pdev);
+ if (pdev->dev.platform_data)
+ rfbi_probe_pdata(pdev);
return 0;
diff --git a/drivers/video/omap2/dss/sdi.c b/drivers/video/omap2/dss/sdi.c
index e6baee2..0155c7e 100644
--- a/drivers/video/omap2/dss/sdi.c
+++ b/drivers/video/omap2/dss/sdi.c
@@ -361,7 +361,8 @@ static int __init omap_sdi_probe(struct platform_device
*pdev)
{
sdi_init_output(pdev);
- sdi_probe_pdata(pdev);
+ if (pdev->dev.platform_data)
+ sdi_probe_pdata(pdev);
return 0;
}
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 5cb983e..f5e8a5b 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -879,7 +879,8 @@ static int __init omap_venchw_probe(struct platform_device
*pdev)
venc_init_output(pdev);
- venc_probe_pdata(pdev);
+ if (pdev->dev.platform_data)
+ venc_probe_pdata(pdev);
return 0;
--
1.7.10.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 00/26] DSS device model change
Hi, To make it possible to add DT support to DSS, and later use the Common Display Framework, we need to change the DSS device model. We currently have a custom dss bus, and omap_dss_devices on that bus, and the aim is to get rid of that bus. The panel devices will be converted occording to the control bus of the panel. For many panels this means that the panel device will become a platform_device. For some, it means the panel devices become i2c or spi devices. This series takes the first step toward that goal. This series: * Converts DPI, HDMI and DSI outputs to work with new style panels * Converts TFP410, Taal and generic-dpi panels to new model * Converts Panda, 4430SDP and Overo boards to use the new panels The non-converted outputs and panels still work, so they can be converted in stages. Note about board files: I only convert a few board files here for example. I have a branch with board file changes for all the affected board files. I did not include them as they are more or less identical. If this series looks good, I will create an independent branch for the arch/arm stuff, so it can be pulled separately. This series can also be found from: git://gitorious.org/linux-omap-dss2/linux.git work/dss-dev-model-review Tomi Tomi Valkeinen (26): OMAPDSS: only probe pdata if there's one OMAPDSS: add omap_dss_find_output() OMAPDSS: add omap_dss_find_output_by_node() OMAPDSS: fix dss_get_ctx_loss_count for DT OMAPDSS: DPI: fix regulators OMAPDSS: SDI: fix regulators OMAPDSS: add panel list OMAPDSS: use the panel list in omap_dss_get_next_device OMAPDSS: don't use dss bus in suspend/resume OMAPDSS: implement display sysfs without dss bus OMAPDSS: Add panel_dev pointer to dssdev OMAPDSS: DPI: new panel registration OMAPDSS: DSI: new panel registration OMAPDSS: HDMI: new panel registration OMAPDSS: TFP410 platform_data changes OMAPDSS: TFP410: convert to platform device OMAPDSS: generic-dpi-panel platform_data changes OMAPDSS: panel-generic-dpi: convert to platform device OMAPDSS: HDMI: convert to platform device OMAPDSS: Taal platform_data changes OMAPDSS: Taal: convert to platform device ARM: OMAP: Panda: use new TFP410 platform driver ARM: OMAP: Panda & SDP: use new HDMI driver ARM: OMAP: 4430SDP: use new Taal driver ARM: OMAP: Overo: use new TFP410 platform driver ARM: OMAP: Overo: use new generic-dpi-panel platform driver arch/arm/mach-omap2/board-overo.c| 95 +++ arch/arm/mach-omap2/dss-common.c | 96 +++ drivers/video/omap2/displays/panel-generic-dpi.c | 141 +++ drivers/video/omap2/displays/panel-taal.c| 294 +- drivers/video/omap2/displays/panel-tfp410.c | 205 +-- drivers/video/omap2/dss/apply.c | 15 +- drivers/video/omap2/dss/core.c | 32 +-- drivers/video/omap2/dss/display-sysfs.c | 126 ++ drivers/video/omap2/dss/display.c| 166 +++- drivers/video/omap2/dss/dpi.c| 59 - drivers/video/omap2/dss/dsi.c| 58 - drivers/video/omap2/dss/dss.c|3 +- drivers/video/omap2/dss/dss.h| 11 +- drivers/video/omap2/dss/hdmi.c | 44 +++- drivers/video/omap2/dss/hdmi_panel.c | 48 +++- drivers/video/omap2/dss/output.c | 26 ++ drivers/video/omap2/dss/rfbi.c |3 +- drivers/video/omap2/dss/sdi.c| 23 +- drivers/video/omap2/dss/venc.c |3 +- include/video/omap-panel-generic-dpi.h |3 + include/video/omap-panel-nokia-dsi.h |1 + include/video/omap-panel-tfp410.h|5 + include/video/omapdss.h | 16 ++ 23 files changed, 940 insertions(+), 533 deletions(-) -- 1.7.10.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
regarding arm: update ARM_ERRATA_430973 Kconfig
Hello, regarding your patch against arch/arm/Kconfig: @@ -1215,7 +1215,7 @@ config ARM_ERRATA_430973 depends on CPU_V7 help This option enables the workaround for the 430973 Cortex-A8 - (r1p0..r1p2) erratum. If a code sequence containing an ARM/Thumb + (r1p*) erratum. If a code sequence containing an ARM/Thumb interworking branch is replaced with another code sequence at the same virtual address, whether due to self-modifying code or virtual to physical address re-mapping, Cortex-A8 does not recover from the I am seeing strange segfault/illegal instructions fixed by enabling ARM_ERRATA_430973 on a TI OMAP3 DM3730, r3p2 IMHO (see below) ARM_ERRATA_430973 is relevant for which processors? have you checked the errata list? I had no luck obtaining it yet cat /proc/cpuinfo Processor : ARMv7 Processor rev 2 (v7l) BogoMIPS: 313.29 Features: swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x3 CPU part: 0xc08 CPU revision: 2 thanks, p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
Register a device tree clock provider for the clocks
on the OMAP4 SoC. Also provide the binding information.
For now we only provide AUXCLKs.
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/clock/omap4-clock.txt | 33
arch/arm/boot/dts/omap4.dtsi |5 ++
arch/arm/mach-omap2/cclock44xx_data.c | 41
3 files changed, 79 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/omap4-clock.txt
diff --git a/Documentation/devicetree/bindings/clock/omap4-clock.txt
b/Documentation/devicetree/bindings/clock/omap4-clock.txt
new file mode 100644
index 000..2845a3f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap4-clock.txt
@@ -0,0 +1,33 @@
+* Clock bindings for Texas Instruments OMAP4 clocks
+
+Required properties:
+- compatible: Should be "ti,omap4-clock"
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. The following is a list of OMAP4 clocks
+and IDs.
+
+ Clock ID
+ --
+ auxclk0_ck 0
+ auxclk1_ck 1
+ auxclk2_ck 2
+ auxclk3_ck 3
+ auxclk4_ck 4
+ auxclk5_ck 5
+
+Example:
+
+aux_clks: scrmclks {
+ compatible = "ti,omap4-clock";
+ #clock-cells = <1>;
+};
+
+hsusb1_phy: hsusb1_phy {
+ compatible = "usb-nop-xceiv";
+ reset-supply = <&hsusb1_reset>;
+ clocks = <&aux_clks 3>;
+ clock-names = "main_clk";
+ clock-frequency = <1920>;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 739bb79..f27548a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -101,6 +101,11 @@
ti,hwmods = "counter_32k";
};
+ clks: clocks {
+ compatible = "ti,omap4-clock";
+ #clock-cells = <1>;
+ };
+
omap4_pmx_core: pinmux@4a100040 {
compatible = "ti,omap4-padconf", "pinctrl-single";
reg = <0x4a100040 0x0196>;
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 3d58f33..a93617b 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "soc.h"
#include "iomap.h"
@@ -1663,6 +1664,44 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, "cpufreq_ck", &dpll_mpu_ck, CK_443X),
};
+/*
+ * List of clocks that can be referenced in device tree
+ * Must match with Documentation/devicetree/bindings/clock/omap4-clock.txt
+ */
+static struct clk *dt_clks[] = {
+ &auxclk0_ck,
+ &auxclk1_ck,
+ &auxclk2_ck,
+ &auxclk3_ck,
+ &auxclk4_ck,
+ &auxclk5_ck,
+};
+
+static struct clk_onecell_data clock_data;
+
+#ifdef CONFIG_OF
+int __init omap4_clk_init_dt(void)
+{
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "ti,omap4-clock");
+ if (np) {
+ clock_data.clks = dt_clks;
+ clock_data.clk_num = ARRAY_SIZE(dt_clks);
+ of_clk_add_provider(np, of_clk_src_onecell_get, &clock_data);
+ }
+
+ return 0;
+}
+
+#else
+
+int __init omap4_clk_init_dt(void)
+{
+ return 0;
+}
+#endif /* CONFIG_OF */
+
int __init omap4xxx_clk_init(void)
{
u32 cpu_clkflg;
@@ -1693,6 +1732,8 @@ int __init omap4xxx_clk_init(void)
omap2_clk_disable_autoidle_all();
+ omap4_clk_init_dt();
+
/*
* On OMAP4460 the ABE DPLL fails to turn on if in idle low-power
* state when turning the ABE clock domain. Workaround this by
--
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] ARM: convert arm/arm64 arch timer to use CLKSRC_OF init
On Monday 25 March 2013, John Stultz wrote: > On 03/25/2013 03:36 PM, Arnd Bergmann wrote: > > On Monday 25 March 2013, Rob Herring wrote: > >> I count integrator-cp, realview, versatile and non-DT VExpress that do > >> this (not surprisingly) and 25 platforms or timer implementations plus > >> arm64 that do sched_clock setup in time_init. What's broken by not > >> moving these earlier? > > timekeeping_init() will leave the persistent_clock_exist variable as > > "false", > > which is read in rtc_suspend() and timekeeping_inject_sleeptime(). > > Are you mixing up the persistent_clock and sched_clock here? From a > generic stand-point they have different requirements. Ah, sorry about that. I had stumbled over the persistent_clock issue earlier and was confusing the two. > > For all I can tell, you will get a little jitter every time you > > do a suspend in that case. Or perhaps it means the system clock > > will be forwarded by the amount of time spent in suspend twice > > after wakeup, but I'm probably misreading the code for that case. > > No, you shouldn't see timekeeping being incremented twice, we check in > rtc_resume code if the persistent clock is present if so we won't inject > any measured suspend time there. But you're probably right that we're > being a little overly paranoid checking the same value twice. Well, the point is that has_persistent_clock() returns false because it is not yet active when the flag gets set in timekeeping_init(), but when we call read_persistent_clock() in timekeeping_suspend(), it will actually return a non-zero time. > As far as the benefit to the persistent clock: it is just a little > better to use, since we can access it earlier in resume, prior to > interrupts being enabled. So we should see less time error introduced > each suspend. Ok. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] channel swapping issue on OMAP3/TWL4030 is back
On 03/25/2013 06:15 PM, Russell King - ARM Linux wrote: > What I'm talking about is having a physical channel scheduler in place > across DMA engines which have more virtual channels than physical > channels. Some DMA engine implementations sort of do this already (eg, > AMBA PL08x stuff) but again, every driver implements this kind of thing > by themselves. I see. So basically you want to grab a DMA channel for the upcoming transfer at issue_pending time. This is fine, but we do not need to have taskelt to do this. If we do it as the amba-pl08x.c does it it is fine. AMBA does not use tasklet and OMAP should not do that either. We might need to lift the code out from the legacy DMA code (and remove the code) from arch/arm/plat-omap/dma.c... >>> I guess we could keep the tasklet, but mark the audio DMA channels as >>> "pre-reserved" and arrange for pre-reserved channels to avoid the >>> tasklet, rather than throwing the tasklet out completely. >> >> Not sure if we really want to pre-reserve the DMA channels for audio: >> on OMAP3 we have 5 McBSP -> 10 DMA channels >> on OMAP4 we have 4 McBSP, one McPDM, one DMIC and one McASP + we have the >> AESS/ABE -> 8 + 2 + 1 + 1 + 8 (AESS/ABE). >> Do we really want to pre-allocate DMA channel for all of these? > > Well, at the moment we are effectively pre-allocating a physical channel > for every virtual channel - as each virtual channel gets allocated. So, > the physical channels are currently being permanently tied up. > > With a scheduling core, we need some way to dynamically reallocate > physical channels depending on the workload presented on the virtual > channels. However, as we're still having to deal with the OMAP private > DMA API, we can only change physical channels from task (or tasklet) > context. > > So, the only way to have audio channels in a condition where they can > be startable immediately in issue_pending is to avoid the tasklet, and > the only way to avoid that tasklet (where that tasklet eventually > becomes the channel scheduler) is to have pre-allocated the physical > channel. The issue has been noticed in audio but it can also affect other drivers as well. It might be only latency/throughput issue for others, while audio suffer with the tasklet based DMA start. >> I have a patch which removes the tasklet from omap-dma.c and it is working >> fine on my systems (OMAP3 Zoom2, BeagleBoard, OMAP4 PandBoard, OMAP4 Blaze). > > I'm sure you have, but that breaks the future direction of the driver > to dynamically allocate the physical channels. > > Had TI not effectively terminated my contract, I might be further forward > with this. As things are, lack of contract and such like, all the OMAP > work I was doing got shelved around Christmas time. If you stop paying > people, they generally stop doing useful work for you... Yeah, that is bad. If it makes you feel a bit better just look up in google: "Texas Instruments France" Hint: I'm in France... -- Péter -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/1] gpio: omap: dts: Move interrupt-controller from #interrupt-cells description
On Fri, Mar 15, 2013 at 2:31 PM, Javier Martinez Canillas
wrote:
> The binding documentation for the OMAP GPIO controller has the
> "#interrupt-cells" property listed before "#interrupt-controller"
> property but its description after.
> This is confusing so we move "#interrupt-cells" after the
> "interrupt-controller" property so is followed by its description.
>
> While being there, change the properties order to be consistent with
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> and Documentation/devicetree/bindings/gpio/gpio.txt.
>
> According with these docs, the order of the properties for a gpio-omap
> device node should be:
>
> gpio-controller;
> #gpio-cells = <2>;
> interrupt-controller;
> #interrupt-cells = <2>;
>
> Reported-by: Stephen Warren
> Signed-off-by: Javier Martinez Canillas
> Acked-by: Jon Hunter
> ---
>
> Changes since v1:
> - Change the properties order to be consistent with the rest of the
> DT bindings docs suggested by Jon Hunter.
>
> Changes since v2:
> - Fix changelog that explained the opposite of what the patch was doing as
> suggested by Benoit Cousson.
>
> .../devicetree/bindings/gpio/gpio-omap.txt |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
> b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
> index bff51a2..a56e3a5 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-omap.txt
> @@ -5,12 +5,12 @@ Required properties:
>- "ti,omap2-gpio" for OMAP2 controllers
>- "ti,omap3-gpio" for OMAP3 controllers
>- "ti,omap4-gpio" for OMAP4 controllers
> +- gpio-controller : Marks the device node as a GPIO controller.
> - #gpio-cells : Should be two.
>- first cell is the pin number
>- second cell is used to specify optional parameters (unused)
> -- gpio-controller : Marks the device node as a GPIO controller.
> +- interrupt-controller: Mark the device node as an interrupt controller.
> - #interrupt-cells : Should be 2.
> -- interrupt-controller: Mark the device node as an interrupt controller
>The first cell is the GPIO number.
>The second cell is used to specify flags:
> bits[3:0] trigger type and level flags:
> @@ -29,8 +29,8 @@ Example:
> gpio4: gpio4 {
> compatible = "ti,omap4-gpio";
> ti,hwmods = "gpio4";
> -#gpio-cells = <2>;
> gpio-controller;
> -#interrupt-cells = <2>;
> +#gpio-cells = <2>;
> interrupt-controller;
> +#interrupt-cells = <2>;
> };
> --
> 1.7.7.6
>
Hello,
any comments on this patch?
Best regards,
Javier
--
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: [alsa-devel] [PATCH] ASoC: omap: Call omap_mcbsp_set_threshold() from mcbsp hw_params
Hi,
On 03/25/2013 04:58 PM, Lars-Peter Clausen wrote:
> The omap PCM driver provides a set_threshold callback which gets called by the
> PCM driver when either playback or capture is started. The only DAI driver
> which
> sets this callback is the mcbsp driver. This patch removes the callback from
> the
> PCM driver and moves the invocation of the omap_mcbsp_set_threshold() function
> to the mcbsp hw_params callback since this is the only place where the
> threshold
> size can change. Doing so allows us to use the default dmaengine PCM trigger
> callback in the omap PCM driver.
>
> Signed-off-by: Lars-Peter Clausen
>
> ---
> Only compile tested, but I don't see why it should not work
Looks good and it also works. My only concern was with this on how I'm going
to handle the upcoming OMAP4/5 AESS/ABE support since there we need to set
custom McBSP threshold...
But looking at the non upstream code I think I can handle things just fine
with this change as well.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Lars-Peter Clausen
> ---
> sound/soc/omap/omap-mcbsp.c | 12 +---
> sound/soc/omap/omap-pcm.c | 33 +
> sound/soc/omap/omap-pcm.h | 1 -
> 3 files changed, 6 insertions(+), 40 deletions(-)
>
> diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c
> index 8d2defd..406fc87 100644
> --- a/sound/soc/omap/omap-mcbsp.c
> +++ b/sound/soc/omap/omap-mcbsp.c
> @@ -62,24 +62,22 @@ enum {
> * Stream DMA parameters. DMA request line and port address are set runtime
> * since they are different between OMAP1 and later OMAPs
> */
> -static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream)
> +static void omap_mcbsp_set_threshold(struct snd_pcm_substream *substream,
> + unsigned int packet_size)
> {
> struct snd_soc_pcm_runtime *rtd = substream->private_data;
> struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
> struct omap_mcbsp *mcbsp = snd_soc_dai_get_drvdata(cpu_dai);
> - struct omap_pcm_dma_data *dma_data;
> int words;
>
> - dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
> -
> /*
>* Configure McBSP threshold based on either:
>* packet_size, when the sDMA is in packet mode, or based on the
>* period size in THRESHOLD mode, otherwise use McBSP threshold = 1
>* for mono streams.
>*/
> - if (dma_data->packet_size)
> - words = dma_data->packet_size;
> + if (packet_size)
> + words = packet_size;
> else
> words = 1;
>
> @@ -245,7 +243,6 @@ static int omap_mcbsp_dai_hw_params(struct
> snd_pcm_substream *substream,
> return -EINVAL;
> }
> if (mcbsp->pdata->buffer_size) {
> - dma_data->set_threshold = omap_mcbsp_set_threshold;
> if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
> int period_words, max_thrsh;
> int divider = 0;
> @@ -276,6 +273,7 @@ static int omap_mcbsp_dai_hw_params(struct
> snd_pcm_substream *substream,
> /* Use packet mode for non mono streams */
> pkt_size = channels;
> }
> + omap_mcbsp_set_threshold(substream, pkt_size);
> }
>
> dma_data->packet_size = pkt_size;
> diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
> index c722c2e..1626fb7 100644
> --- a/sound/soc/omap/omap-pcm.c
> +++ b/sound/soc/omap/omap-pcm.c
> @@ -129,37 +129,6 @@ static int omap_pcm_hw_free(struct snd_pcm_substream
> *substream)
> return 0;
> }
>
> -static int omap_pcm_trigger(struct snd_pcm_substream *substream, int cmd)
> -{
> - struct snd_soc_pcm_runtime *rtd = substream->private_data;
> - struct omap_pcm_dma_data *dma_data;
> - int ret = 0;
> -
> - dma_data = snd_soc_dai_get_dma_data(rtd->cpu_dai, substream);
> -
> - switch (cmd) {
> - case SNDRV_PCM_TRIGGER_START:
> - case SNDRV_PCM_TRIGGER_RESUME:
> - case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
> - /* Configure McBSP internal buffer usage */
> - if (dma_data->set_threshold)
> - dma_data->set_threshold(substream);
> - break;
> -
> - case SNDRV_PCM_TRIGGER_STOP:
> - case SNDRV_PCM_TRIGGER_SUSPEND:
> - case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
> - break;
> - default:
> - ret = -EINVAL;
> - }
> -
> - if (ret == 0)
> - ret = snd_dmaengine_pcm_trigger(substream, cmd);
> -
> - return ret;
> -}
> -
> static snd_pcm_uframes_t omap_pcm_pointer(struct snd_pcm_substream
> *substream)
> {
> snd_pcm_uframes_t offset;
> @@ -208,7 +177,7 @@ static struct snd_pcm_ops omap_pcm_ops = {
> .ioctl = snd_pcm_lib_ioctl,
> .hw_params = omap_pcm_hw_params,
> .hw_free= omap_pcm_hw_free,
> - .trigger= omap_pcm_trigger,
> + .trigger= snd_dmaeng
