Re: [PATCH 0/4] Cleanup legacy OMAP IOMMU device creation
Hi Tony, On 09/16/2015 06:48 PM, Suman Anna wrote: > Hi Tony, > > The following series removes the legacy platform device creation > logic for OMAP IOMMU devices. I will cleanup the legacy support > from the OMAP IOMMU driver in a subsequent merge window after > this series makes it to mainline. > > Patches are based on 4.3-rc1 + the OMAP3 ISP instantiation cleanup > patch [1]. All the patches need to be picked up sequentially, > otherwise a NULL pointer dereference crash might be seen on OMAP3 > legacy boots as the dev attribute structure is deferenced directly > in mach-omap2/omap-iommu.c during platform data creation. Also, the > last patch removes the structure definition altogether, so will > cause build issues if picked separately from the hwmod cleanup > patches. > > I do not have any boards where I can still perform a legacy-style > boot, so patches verified using DT-boot only. > > regards > Suman > > [1] https://patchwork.kernel.org/patch/6806891/ > > Suman Anna (4): > ARM: OMAP2+: Remove legacy device instantiation of IOMMUs > ARM: OMAP3: hwmod data: Remove legacy IOMMU data > ARM: OMAP4: hwmod data: Remove legacy IOMMU attr and addrs > ARM: OMAP2+: Remove omap_mmu_dev_attr structure Ping on this series. You should be able to pick up atleast patch 1 if not picking all, now that the OMAP3 ISP cleanup patch is staged in your omap-for-4.4/cleanup branch. Thanks Suman > > arch/arm/mach-omap2/omap-iommu.c | 66 > -- > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 42 --- > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 31 -- > include/linux/platform_data/iommu-omap.h | 9 > 4 files changed, 148 deletions(-) > delete mode 100644 arch/arm/mach-omap2/omap-iommu.c > -- 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/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
On 10/21/2015 11:42 PM, Jassi Brar wrote: > On 22 October 2015 at 05:35, Suman Anna <s-a...@ti.com> wrote: > >>> Anyways I am OK too, if you guys want to fix it with a platform >>> specific quirk. Let me know I'll pick this patch. >> >> I haven't gotten a chance to try #1, and I won't be able to look at it >> atleast for another month. I suggest that you go ahead and pick this >> patch up, as a quirk is needed in one form or the other for #2, and #1 >> is anyways a bigger change that will affect all our IPC stacks across >> all pairs of MPU - remote processors on different SoCs. >> > Yeah that is the reason I offered to pick this patch as such. > OK I'll take this patch. Thanks a lot. We will be a lot closer to get PM working on AM335/AM437x SoCs. 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: [PATCH 1/2] ARM: OMAP2+: Remove legacy mailbox device instantiation
Hi Tony, On 09/14/2015 06:37 PM, Suman Anna wrote: > The legacy-style mailbox device creation is supported currently > only for OMAP3, as all other SoCs are DT-boot only. Even on this > SoC, there are no client drivers that utilize these mailbox devices. > So, clean up the legacy-style mailbox device instantiation logic. > The mailbox devices are already present and supported for the DT > boot on OMAP3. > > Signed-off-by: Suman Anna <s-a...@ti.com> > --- > arch/arm/mach-omap2/devices.c | 28 > 1 file changed, 28 deletions(-) > Ping, can you pick up this patch for your cleanup branch? FYI, Paul is queueing Patch 2. 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: [PATCH v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
Hi Jassi, On 10/20/2015 11:44 PM, Jassi Brar wrote: > On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlachwrote: >> The mailbox framework controls the transmission queue and requires >> either its controller implementations or clients to run the state >> machine for the Tx queue. The OMAP mailbox controller uses a Tx-ready >> interrupt as the equivalent of a Tx-done interrupt to run this Tx >> queue state-machine. >> >> The WkupM3 processor on AM33xx and AM43xx SoCs is used to offload >> certain PM tasks, like doing the necessary operations for Device >> PM suspend/resume or for entering lower c-states during cpuidle. >> >> The CPUIdle on AM33xx requires the messages to be sent without >> having to trigger the Tx-ready interrupts, as the interrupt >> would immediately terminate the CPUIdle operation. Support for >> this has been added by introducing a DT quirk, "ti,mbox-send-noirq" >> and using it to modify the normal OMAP mailbox controller behavior >> on the sub-mailboxes used to communicate with the WkupM3 remote >> processor. This also requires the wkup_m3_ipc driver to adjust >> its mailbox usage logic to run the Tx state machine. >> > Probably Suman already updated you on what was discussed about this > patch at Connect-SFO. My suggestion was to drive TX poll-based (I > know, I know...) because the "interrupt-driven" is just an impression, > it is not really. You get the interrupt as soon as you enable it > because it is the "FIFO not-full" interrupt which is always because > there is always space left after writing to the fifo. The cons are > that it buffers messages hidden from the client while abusing the irq. > If you guys could break away from the "interrupt-driven" illusion and > use polling which it actually is, everything falls into place and you > avoid the "ti,mbox-send-noirq" quirk. Looking at this closely, even with that approach, we would still need a quirk to deal with the weird behavior of our wakeup m3. Essentially we have two independent things: 1. Tx state machine (currently interrupt driven) for ticking the mailbox core tx state machine. 2. A quirk that we need for dealing with Wakeup M3 behavior, MPU needs to take out the message on behalf of WkupM3 processor after transmission and clearing the IP-level interrupt intended for WkupM3. This will be irrespective of the Tx state machine choice, and this needs to be different only on the specific mbox channel used to talk with WkupM3 processor. Previously, we were doing #2 in the OMAP mailbox regular interrupt handler (handles both Rx and Tx interrupts) as part of the Rx interrupt handler with the rx mbox variables reflecting those of the WkupM3 processor. But when we remove the interrupt processing, we now actually need to add code to deal with this. > Anyways I am OK too, if you guys want to fix it with a platform > specific quirk. Let me know I'll pick this patch. I haven't gotten a chance to try #1, and I won't be able to look at it atleast for another month. I suggest that you go ahead and pick this patch up, as a quirk is needed in one form or the other for #2, and #1 is anyways a bigger change that will affect all our IPC stacks across all pairs of MPU - remote processors on different SoCs. 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: [PATCH] ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory
On 10/14/2015 03:12 PM, Arnd Bergmann wrote: > On Wednesday 14 October 2015 09:17:56 Tony Lindgren wrote: >> * Arnd Bergmann[151014 02:20]: >>> On Tuesday 13 October 2015 16:13:20 Tony Lindgren wrote: On boards with more than 2GB of RAM booting goes wrong with things not working and we're getting lots of l3 warnings: WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x260/0x384() 4400.ocp:L3 Custom Error: MASTER MMC6 TARGET DMM1 (Idle): Data Access in User mode during Functional access ... [] (scsi_add_host_with_dma) from [] (ata_scsi_add_hosts+0x5c/0x18c) [] (ata_scsi_add_hosts) from [] (ata_host_register+0x150/0x2cc) [] (ata_host_register) from [] (ata_host_activate+0xd4/0x124) [] (ata_host_activate) from [] (ahci_host_activate+0x5c/0x194) [] (ahci_host_activate) from [] (ahci_platform_init_host+0x1f0/0x3f0) [] (ahci_platform_init_host) from [] (ahci_probe+0x70/0x98) [] (ahci_probe) from [] (platform_drv_probe+0x54/0xb4) Let's fix the issue by enabling ZONE_DMA for LPAE. Signed-off-by: Tony Lindgren >>> >>> I suspect this is not the correct fix, even if it works around the problem. >>> >>> Am I right that the AHCI device can access the first 4GB of address space >>> using 32-bit DMA, and that any RAM beyond 2GB is above that limit? >> >> Yes the memory above 2GB is at 0x3. The same problem is there at >> least >> with MMC too. >> >>> Does the ZONE_DMA have the same size? If not, you get more bounce buffers >>> than you want, which is bad for performance/ >> >> Hmm good question. I guess we should set .dma_zone_size = SZ_2G in this >> case then as only 2GB of RAM can directly be accessed. > > I think you need ".dma_zone_size = SZ_4G", but I'm not completely sure > whether this takes PHYS_OFFSET into account or not. > >>> Another problem here is that it only works with the SCSI and net subsystems >>> that have a hack in there to create manual bounce buffers, but other drivers >>> that can do DMA to high addresses will not know about this. >> >> OK good to know. >> >>> The right solution would be to force the use of an IOMMU, and if that not >>> works, add support for SWIOTLB on ARM. >> >> Suman might have some accelerators in mind we could use for DMA. Only MMUs that we have on OMAP5 are the ones for the processors on the SoC - MPU, DSP or the IPU (Dual-Cortex M4). There is one eDMA engine within the DSP subsystem that goes through the DSP MMU, but this is typically used by software running on DSP. regards Suman >> >> For SWIOTLB, It seems we have it for arm64 but not for arm? > > Correct. A number of people have run into problems with this before, but > it has never been added to the kernel. At some point, I tried to help > Peter Senna Tschudin get it implemented, but I think he gave up when it > turned out that the platform he was using to test this did not need it > after all. > > The reason we have it on ARM64 is that you are completely screwed there > if you have no IOMMU but use a 32-bit DMA master, while on 32-bit platforms > most of the time you don't have memory above 4GB, and if you do then most > of the time you don't have any DMA masters other than network and scsi > (including sata) on them, or you have an IOMMU for each one. > > 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: [REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node
Hi Tony, On 10/12/2015 04:43 PM, Tony Lindgren wrote: > * Suman Anna <s-a...@ti.com> [151002 16:27]: >> The DSP_SYSTEM sub-module is a dedicated system control logic >> module present within a DRA7 DSP processor sub-system. This >> module is responsible for power management, clock generation >> and connection to the device PRCM module. >> >> Add a syscon node for this module for the DSP1 processor >> sub-system. This is added as a syscon node as it is a common >> configuration module that can be used by the different IOMMU >> instances and the corresponding remoteproc device. >> >> The node is added to the common dra7.dtsi file, as the DSP1 >> processor sub-system is mostly common across all the variants >> of the DRA7 SoC family. >> >> Signed-off-by: Suman Anna <s-a...@ti.com> >> --- >> arch/arm/boot/dts/dra7.dtsi | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi >> index e289c706d27d..62055094e8d5 100644 >> --- a/arch/arm/boot/dts/dra7.dtsi >> +++ b/arch/arm/boot/dts/dra7.dtsi >> @@ -292,6 +292,11 @@ >> #thermal-sensor-cells = <1>; >> }; >> >> +dsp1_system: dsp_system@40d0 { >> +compatible = "syscon"; >> +reg = <0x40d0 0x100>; >> +}; >> + >> sdma: dma-controller@4a056000 { >> compatible = "ti,omap4430-sdma"; >> reg = <0x4a056000 0x1000>; > > Hmm so why would you want to set up a complete device as a syscon > mapping rather than just doing ioremap on it? > > What drivers will be sharing access to these registers? Two different instances of the MMU for now, both get probed independently. But there are other registers which a remoteproc driver will mostly be interested in (like DSP_SYS_STAT for knowing the C66x idle/active status). 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: [PATCH] arm: omap2: timer: don't disable our timers
On 10/06/2015 12:14 PM, Felipe Balbi wrote: > > Hi, > > Suman Anna <s-a...@ti.com> writes: >>>>>> On 10/05/2015 02:48 PM, Balbi, Felipe wrote: >>>>>>> We actually want these devices to be created because >>>>>>> we will be moving timers to drivers/clocksource and >>>>>>> this will prevent them from probing. >>>>>> >>>>>> This logic is also used to remove the secure timer from being >>>>>> registered to the kernel on HS devices, while allowing the timer to be >>>>>> available on GP devices. Your patch actually would break that >>>>>> functionality. I suggest that you look at the history of the code that >>>>> >>>>> heh, that's a silly way of doing so. Could just detect if we're running >>>>> on HS or not. >>>> >>>> This function is invoked only after detecting that we are running on a >>>> HS device. >>> >>> What actually disables the timer is omap_get_timer_dt() and that's >>> called in more than one place. >> >> Yes indeed, and this patch is changing the behavior of >> omap_get_timer_dt(), so you have to check all call-sites. Also, one >> another thing is that this trick was used for DT boots so that the >> timers used for clocksource and clockevent are eliminated from the >> omap_dm_timer_request() API. The legacy boot used a specific API to mark >> those as reserved so that the _request API does not give them out. >> Granted that it may not have been the best approach, but that needs a >> solution if you change the behavior of this API. > > no doubt this needs a solution, but seesm like a solution here will have > to be incremental. See new revision of my series. I'm now skipping 32k > only and keeping it enabled so drivers/clocksource/ can use it. Yeah, have noticed, and it's better for the current problem at hand than this patch. > >>>>>>> Signed-off-by: Felipe Balbi <ba...@ti.com> >>>>>>> --- >>>>>>> >>>>>>> Tony, I wonder if you can get merged as a fix, or do you >>>>>>> prefer receiving it together with my timer series ? >>>>>> >>>>>> NAK for rc, as it breaks other stuff. >>>>> >>>>> a single stuff which is likely easy enough to fix. But fair enough >>>> >>>> Don't think this patch is fixing any critical bug either, better to club >>>> it with your cleanup series. >>> >>> it is kinda critical when you consider that the timer is disabled >>> outside of the soc type detection. >> >> This has been like this since DMTimer is converted to DT (from 3.8 >> kernel), and is a need for your counter32k clocksource series. The >> problem seems to stem from the reuse of omap_get_timer_dt for counter32k >> nodes. A better solution would be to remove the omap_get_timer_dt() from >> omap2_sync32k_clocksource_init() code and just replace it with >> of_find_compatible_node - you seem to be limiting the majority of that >> function to legacy mode in Patch 10 of your RFC series anyways. > > I still need omap_hwmod_enable() to be called, that's why it's still > used. I don't think replacing it with of_find_compatible_node() will buy > us much, we will still need to check for of_device_is_available() > anyway. Sure we skip all the timer flags (alwon, dsp, pwm, secure), but > that really isn't big deal. Yeah, I would think the counter_32k and the timer code will have to be decoupled in the future anyway, so it is best to localize the change now rather than later, so that the omap2_sync32k_clocksource_init() function can be decoupled cleanly from the timr code. The check for of_device_is_available may be moot if this device is always needed. But as long as current timer functionality is unchanged, I am not too particular about this. If it is always needed, the check for of_device regards Suman > When converting gptimer to clocksource, then I'll look at what I can do > for the timer request side of things. For now, things are working, > apparently without regressions (or at least I couldn't catch any so far) > and it seems clean enough that it could possibly be queued for v4.4 > merge window. For v4.5 I'll look at this again and try to figure out how > to handle gptimer. -- 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 04/11] arm: omap2: timer: provide generic sync32k_timer_init function
On 10/06/2015 12:02 PM, Balbi, Felipe wrote: > instead of constantly defining a small wrapper > around __omap_sync32k_timer_init(), let's define > a generic one which can be used by all OMAPs. > > Signed-off-by: Felipe Balbi> --- > arch/arm/mach-omap2/board-generic.c | 10 +- > arch/arm/mach-omap2/board-ldp.c | 2 +- > arch/arm/mach-omap2/board-rx51.c| 2 +- > arch/arm/mach-omap2/common.h| 3 +-- > arch/arm/mach-omap2/timer.c | 20 +++- > 5 files changed, 11 insertions(+), 26 deletions(-) > > diff --git a/arch/arm/mach-omap2/board-generic.c > b/arch/arm/mach-omap2/board-generic.c > index 9df14ed7dab1..871db0f0fa66 100644 > --- a/arch/arm/mach-omap2/board-generic.c > +++ b/arch/arm/mach-omap2/board-generic.c > @@ -46,7 +46,7 @@ DT_MACHINE_START(OMAP242X_DT, "Generic OMAP2420 (Flattened > Device Tree)") > .map_io = omap242x_map_io, > .init_early = omap2420_init_early, > .init_machine = omap_generic_init, > - .init_time = omap2_sync32k_timer_init, > + .init_time = omap_sync32k_timer_init, > .dt_compat = omap242x_boards_compat, > .restart= omap2xxx_restart, > MACHINE_END > @@ -63,7 +63,7 @@ DT_MACHINE_START(OMAP243X_DT, "Generic OMAP2430 (Flattened > Device Tree)") > .map_io = omap243x_map_io, > .init_early = omap2430_init_early, > .init_machine = omap_generic_init, > - .init_time = omap2_sync32k_timer_init, > + .init_time = omap_sync32k_timer_init, > .dt_compat = omap243x_boards_compat, > .restart= omap2xxx_restart, > MACHINE_END > @@ -82,7 +82,7 @@ DT_MACHINE_START(OMAP3_N900_DT, "Nokia RX-51 board") > .init_early = omap3430_init_early, > .init_machine = omap_generic_init, > .init_late = omap3_init_late, > - .init_time = omap3_sync32k_timer_init, > + .init_time = omap_sync32k_timer_init, > .dt_compat = n900_boards_compat, > .restart= omap3xxx_restart, > MACHINE_END > @@ -100,7 +100,7 @@ DT_MACHINE_START(OMAP3_DT, "Generic OMAP3 (Flattened > Device Tree)") > .init_early = omap3430_init_early, > .init_machine = omap_generic_init, > .init_late = omap3_init_late, > - .init_time = omap3_sync32k_timer_init, > + .init_time = omap_sync32k_timer_init, > .dt_compat = omap3_boards_compat, > .restart= omap3xxx_restart, > MACHINE_END > @@ -116,7 +116,7 @@ DT_MACHINE_START(OMAP36XX_DT, "Generic OMAP36xx > (Flattened Device Tree)") > .init_early = omap3630_init_early, > .init_machine = omap_generic_init, > .init_late = omap3_init_late, > - .init_time = omap3_sync32k_timer_init, > + .init_time = omap_sync32k_timer_init, > .dt_compat = omap36xx_boards_compat, > .restart= omap3xxx_restart, > MACHINE_END > diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c > index c2975af4cd5d..0d3a57c6931f 100644 > --- a/arch/arm/mach-omap2/board-ldp.c > +++ b/arch/arm/mach-omap2/board-ldp.c > @@ -424,6 +424,6 @@ MACHINE_START(OMAP_LDP, "OMAP LDP board") > .init_irq = omap3_init_irq, > .init_machine = omap_ldp_init, > .init_late = omap3430_init_late, > - .init_time = omap3_sync32k_timer_init, > + .init_time = omap_sync32k_timer_init, > .restart= omap3xxx_restart, > MACHINE_END > diff --git a/arch/arm/mach-omap2/board-rx51.c > b/arch/arm/mach-omap2/board-rx51.c > index 2d1e5a6beb85..830256c434ec 100644 > --- a/arch/arm/mach-omap2/board-rx51.c > +++ b/arch/arm/mach-omap2/board-rx51.c > @@ -136,6 +136,6 @@ MACHINE_START(NOKIA_RX51, "Nokia RX-51 board") > .init_irq = omap3_init_irq, > .init_machine = rx51_init, > .init_late = omap3430_init_late, > - .init_time = omap3_sync32k_timer_init, > + .init_time = omap_sync32k_timer_init, > .restart= omap3xxx_restart, > MACHINE_END > diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h > index 92e92cfc2775..844ad031f7f0 100644 > --- a/arch/arm/mach-omap2/common.h > +++ b/arch/arm/mach-omap2/common.h > @@ -88,8 +88,7 @@ static inline int omap_mux_late_init(void) > > extern void omap2_init_common_infrastructure(void); > > -extern void omap2_sync32k_timer_init(void); > -extern void omap3_sync32k_timer_init(void); > +extern void omap_sync32k_timer_init(void); > extern void omap3_secure_sync32k_timer_init(void); > extern void omap3_gptimer_timer_init(void); > extern void omap4_local_timer_init(void); > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c > index 976ff9fa3594..d14e25b2d7a4 100644 > --- a/arch/arm/mach-omap2/timer.c > +++ b/arch/arm/mach-omap2/timer.c > @@ -608,21 +608,13 @@ static void __init __omap_sync32k_timer_init(int > clkev_nr, const char *clkev_src >
Re: [PATCH] arm: omap2: timer: don't disable our timers
Hi Felipe, On 10/05/2015 02:48 PM, Balbi, Felipe wrote: > We actually want these devices to be created because > we will be moving timers to drivers/clocksource and > this will prevent them from probing. This logic is also used to remove the secure timer from being registered to the kernel on HS devices, while allowing the timer to be available on GP devices. Your patch actually would break that functionality. I suggest that you look at the history of the code that >>> >>> heh, that's a silly way of doing so. Could just detect if we're running >>> on HS or not. >> >> This function is invoked only after detecting that we are running on a >> HS device. > > What actually disables the timer is omap_get_timer_dt() and that's > called in more than one place. Yes indeed, and this patch is changing the behavior of omap_get_timer_dt(), so you have to check all call-sites. Also, one another thing is that this trick was used for DT boots so that the timers used for clocksource and clockevent are eliminated from the omap_dm_timer_request() API. The legacy boot used a specific API to mark those as reserved so that the _request API does not give them out. Granted that it may not have been the best approach, but that needs a solution if you change the behavior of this API. > originally added this logic - this function seems to be designed to actually remove the node. The OMAP DMTimer provides an API to request timers, and I think this logic was used to eliminate giving out the timers used for clocksource and clockevent when the driver got adapted to DT. >>> >>> again not the best way of achieving what you want. In any case, other >>> than ir-rx51.c who's using that API ? Seems like we could just pass a >>> phandle to ir-rx51 and be done with it. >> >> We will gain a user from OMAP remoteproc driver as well (out of tree at >> the moment, but it does follow the DT phandle and >> omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is >> converted to DT, and also some of the API are alive just because of the >> continued OMAP3 legacy boot support. Guess, it is a just a question of >> not breaking existing API until we kill some of them. > > sure, but until remoteproc gets upstream, it's only 1 user ;-) > > Signed-off-by: Felipe Balbi> --- > > Tony, I wonder if you can get merged as a fix, or do you > prefer receiving it together with my timer series ? NAK for rc, as it breaks other stuff. >>> >>> a single stuff which is likely easy enough to fix. But fair enough >> >> Don't think this patch is fixing any critical bug either, better to club >> it with your cleanup series. > > it is kinda critical when you consider that the timer is disabled > outside of the soc type detection. This has been like this since DMTimer is converted to DT (from 3.8 kernel), and is a need for your counter32k clocksource series. The problem seems to stem from the reuse of omap_get_timer_dt for counter32k nodes. A better solution would be to remove the omap_get_timer_dt() from omap2_sync32k_clocksource_init() code and just replace it with of_find_compatible_node - you seem to be limiting the majority of that function to legacy mode in Patch 10 of your RFC series anyways. 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: [PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node
On 10/06/2015 02:52 AM, Tony Lindgren wrote: > * Felipe Balbi[151005 17:51]: >> >> according to Tony we should avoid using status at all for in-SoC >> devices. >> >> Tony, can you confirm I understood you correctly ? > > Yes. With status = "disabled" kernel completely ignores the > device and struct device is not created at all even with the > device being there. In general we're better off trying to > probe the device and idle it. > > The only time we really want to mark something with > status = "disabled" is if some coprocessor firmware is > using that device and the kernel should not touch it at > all. Not always, since some of the PM clocking logic depends on the state machine variables within the kernel. We are also using this to deal with paper-spins (atleast in the DRA7 case) and the DTS include model, wherein certain instances may not be present on all variations of the SoC, and enabled specifically on the instances that matter. Obviously, it could be done the other way too, but as far as what Nishanth mentioned sometime back, we are following the former for DRA7. In anycase, the status property on the Timer12 node can be removed, it doesn't fall into the above category, and we are fixing it up properly on HS devices in the kernel. 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: [PATCH 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
On 10/05/2015 11:58 AM, Tony Lindgren wrote: > * Suman Anna <s-a...@ti.com> [151005 09:47]: >> Tony, >> >> On 10/03/2015 12:29 PM, kbuild test robot wrote: >>> Hi Suman, >>> >>> [auto build test results on v4.3-rc3 -- if it's inappropriate base, please >>> ignore] >>> >>> config: arm-omap1_defconfig (attached as .config) >>> reproduce: >>> wget >>> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross >>> -O ~/bin/make.cross >>> chmod +x ~/bin/make.cross >>> # save the attached .config to linux build tree >>> make.cross ARCH=arm >>> >>> All error/warnings (new ones prefixed by >>): >>> >>>arch/arm/plat-omap/dmtimer.c: In function 'omap_dm_timer_set_source': >>>>> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of >>>>> function 'clk_hw_get_num_parents' [-Werror=implicit-function-declaration] >>> if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) >>> ^ >>>>> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of >>>>> function '__clk_get_hw' [-Werror=implicit-function-declaration] >>>cc1: some warnings being treated as errors >>> >>> vim +/clk_hw_get_num_parents +509 arch/arm/plat-omap/dmtimer.c >>> >>>503 return pdata->set_timer_src(timer->pdev, >>> source); >>>504 >>>505 if (IS_ERR(timer->fclk)) >>>506 return -EINVAL; >>>507 >>>508 /* Check if the clock has parents if not no point >>> checking */ >>> > 509 if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) >>>510 return 0; >> >> CONFIG_COMMON_CLK is not defined for OMAP1. So, are you ok if I enclose >> this within #ifdef CONFIG_COMMON_CLK? > > Yes, or maybe you can just clk_get_rate() on the 32k oscillator? > > Boards with no 32k oscillator should set the rate for that 0 zero. Well, this API is about setting the timer clk's mux source, and not really dealing with the clk rate or just setting it to the 32k oscillator. A 32k is usually one of the mux parents (if the timer has them). If there is a way to find if the clk is a mux clock, then that check would be ideal. But since no such thing exists, so I will go ahead and fix this by adding the #ifdef check. 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: [PATCH] arm: omap2: timer: don't disable our timers
Hi Felipe, On 10/05/2015 02:48 PM, Balbi, Felipe wrote: > We actually want these devices to be created because > we will be moving timers to drivers/clocksource and > this will prevent them from probing. This logic is also used to remove the secure timer from being registered to the kernel on HS devices, while allowing the timer to be available on GP devices. Your patch actually would break that functionality. I suggest that you look at the history of the code that originally added this logic - this function seems to be designed to actually remove the node. The OMAP DMTimer provides an API to request timers, and I think this logic was used to eliminate giving out the timers used for clocksource and clockevent when the driver got adapted to DT. > > Signed-off-by: Felipe Balbi> --- > > Tony, I wonder if you can get merged as a fix, or do you > prefer receiving it together with my timer series ? NAK for rc, as it breaks other stuff. regards Suman > > arch/arm/mach-omap2/timer.c | 11 +-- > 1 file changed, 1 insertion(+), 10 deletions(-) > > diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c > index 0ff676273b4b..0c00138d7bd5 100644 > --- a/arch/arm/mach-omap2/timer.c > +++ b/arch/arm/mach-omap2/timer.c > @@ -136,12 +136,6 @@ static struct clock_event_device clockevent_gpt = { > .tick_resume= omap2_gp_timer_shutdown, > }; > > -static struct property device_disabled = { > - .name = "status", > - .length = sizeof("disabled"), > - .value = "disabled", > -}; > - > static const struct of_device_id omap_timer_match[] __initconst = { > { .compatible = "ti,omap2420-timer", }, > { .compatible = "ti,omap3430-timer", }, > @@ -161,9 +155,7 @@ static const struct of_device_id omap_timer_match[] > __initconst = { > * > * Helper function to get a timer during early boot using device-tree for use > * as kernel system timer. Optionally, the property argument can be used to > - * select a timer with a specific property. Once a timer is found then mark > - * the timer node in device-tree as disabled, to prevent the kernel from > - * registering this timer as a platform device and so no one else can use it. > + * select a timer with a specific property. > */ > static struct device_node * __init omap_get_timer_dt(const struct > of_device_id *match, >const char *property) > @@ -183,7 +175,6 @@ static struct device_node * __init > omap_get_timer_dt(const struct of_device_id * > of_get_property(np, "ti,timer-secure", NULL))) > continue; > > - of_add_property(np, _disabled); > return np; > } > > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: omap2: timer: don't disable our timers
Hi Felipe, >> >> On 10/05/2015 02:48 PM, Balbi, Felipe wrote: >>> We actually want these devices to be created because >>> we will be moving timers to drivers/clocksource and >>> this will prevent them from probing. >> >> This logic is also used to remove the secure timer from being >> registered to the kernel on HS devices, while allowing the timer to be >> available on GP devices. Your patch actually would break that >> functionality. I suggest that you look at the history of the code that > > heh, that's a silly way of doing so. Could just detect if we're running > on HS or not. This function is invoked only after detecting that we are running on a HS device. > >> originally added this logic - this function seems to be designed to >> actually remove the node. The OMAP DMTimer provides an API to request >> timers, and I think this logic was used to eliminate giving out the >> timers used for clocksource and clockevent when the driver got adapted >> to DT. > > again not the best way of achieving what you want. In any case, other > than ir-rx51.c who's using that API ? Seems like we could just pass a > phandle to ir-rx51 and be done with it. We will gain a user from OMAP remoteproc driver as well (out of tree at the moment, but it does follow the DT phandle and omap_dm_timer_request_by_node semantics). I do not think ir-rx51.c is converted to DT, and also some of the API are alive just because of the continued OMAP3 legacy boot support. Guess, it is a just a question of not breaking existing API until we kill some of them. > >>> Signed-off-by: Felipe Balbi>>> --- >>> >>> Tony, I wonder if you can get merged as a fix, or do you >>> prefer receiving it together with my timer series ? >> >> NAK for rc, as it breaks other stuff. > > a single stuff which is likely easy enough to fix. But fair enough Don't think this patch is fixing any critical bug either, better to club it with your cleanup series. 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
[PATCH v2 2/4] ARM: OMAP2+: timer: Remove secure timer for DRA7xx HS devices
Timer 12 on DRA7 SoCs is reserved for secure usage on high-secure (HS) devices. The timer cannot be used by the kernel on HS devices, but is available on regular general purpose (GP) devices. This is similar to the behavior on OMAP3 devices, so extend the logic used in commit ad24bde8f102 ("ARM: OMAP3: Dynamically disable secure timer nodes for secure devices") to remove the secure timer on DRA7xx SoCs at run-time based on the SoC device type. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/timer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index a55655127ef2..1e346aa0a687 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -193,8 +193,8 @@ static struct device_node * __init omap_get_timer_dt(const struct of_device_id * /** * omap_dmtimer_init - initialisation function when device tree is used * - * For secure OMAP3 devices, timers with device type "timer-secure" cannot - * be used by the kernel as they are reserved. Therefore, to prevent the + * For secure OMAP3/DRA7xx devices, timers with device type "timer-secure" + * cannot be used by the kernel as they are reserved. Therefore, to prevent the * kernel registering these devices remove them dynamically from the device * tree on boot. */ @@ -202,7 +202,7 @@ static void __init omap_dmtimer_init(void) { struct device_node *np; - if (!cpu_is_omap34xx()) + if (!cpu_is_omap34xx() && !soc_is_dra7xx()) return; /* If we are a secure device, remove any secure timer nodes */ -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] ARM: dts: DRA7: Add timer12 node
Add the DT node for Timer12 present on DRA7 family of SoCs. Timer12 is present in PD_WKUPAON power domain, and has the same capabilities as the other timers, except for the fact that it serves as a secure timer on HS devices and is clocked only from the secure 32K clock. The node is marked disabled for now, and the kernel should refrain from using this secure timer on HS devices. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra7.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index e289c706d27d..37d632dad576 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -762,6 +762,16 @@ ti,hwmods = "timer11"; }; + timer12: timer@4ae2 { + compatible = "ti,omap5430-timer"; + reg = <0x4ae2 0x80>; + interrupts = ; + ti,hwmods = "timer12"; + ti,timer-alwon; + ti,timer-secure; + status = "disabled"; + }; + timer13: timer@48828000 { compatible = "ti,omap5430-timer"; reg = <0x48828000 0x80>; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
The omap_dm_timer_set_source() function provides a means for client users to configure the mux parent for a GPTimer's functional clock. However, not all timers are configurable (Eg: Timer12 on DRA7 is fed by an internal 32k oscillator clock, and does not have configurable parent clocks). So, check for such cases and proceed with out throwing an error. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/plat-omap/dmtimer.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 8ca94d379bc3..4c48b52c4a7c 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -36,6 +36,7 @@ */ #include +#include #include #include #include @@ -504,6 +505,12 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source) if (IS_ERR(timer->fclk)) return -EINVAL; +#if defined(CONFIG_COMMON_CLK) + /* Check if the clock has configurable parents */ + if (clk_hw_get_num_parents(__clk_get_hw(timer->fclk)) < 2) + return 0; +#endif + switch (source) { case OMAP_TIMER_SRC_SYS_CLK: parent_name = "timer_sys_ck"; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] DRA7 Timer12 Support
Hi Tony, This is a revised version of the DRA7 Timer12 support patch series [1]. The series mainly is respun to fix a build issue caused by Patch1 [2] with omap1_defconfig due to the absence of Common Clock framework for OMAP1. Only Patch 1 is modified from the previous series. I have also revised the check slightly to fix another issue seen when requesting Timer12 on OMAP3, as that is a fixed clock and does return back with a parent count of 1. Series baselined on v4.3-rc3 just like the original series, and tested on all generations (AMx3x, OMAP4, OMAP5 and DRA7) except OMAP1 and OMAP2 generations. regards Suman [1] http://marc.info/?l=linux-omap=144372799601354=2 [2] https://patchwork.kernel.org/patch/7311021/ Suman Anna (4): ARM: OMAP: dmtimer: check for fixed timers during config ARM: OMAP2+: timer: Remove secure timer for DRA7xx HS devices ARM: dts: DRA7: Add timer12 node ARM: DRA7: hwmod: Add data for GPTimer 12 arch/arm/boot/dts/dra7.dtsi | 10 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +-- arch/arm/mach-omap2/timer.c | 6 +++--- arch/arm/plat-omap/dmtimer.c | 7 ++ 4 files changed, 54 insertions(+), 5 deletions(-) -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: DRA7: hwmod: Add data for GPTimer 12
Add the hwmod data for GPTimer 12. GPTimer 12 is present in WKUPAON power domain and is clocked from a secure 32K clock. GPTimer 12 serves as a secure timer on HS devices, but is available for kernel on regular GP devices. The hwmod link is registered only on GP devices. The hwmod data also reused the existing timer class instead of reintroducing the identical dra7xx_timer_secure_sysc class which was dropped in commit edec17863362 ("ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4"). Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c index 562247bced49..37a10f87fbcd 100644 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c @@ -1929,6 +1929,20 @@ static struct omap_hwmod dra7xx_timer11_hwmod = { }, }; +/* timer12 */ +static struct omap_hwmod dra7xx_timer12_hwmod = { + .name = "timer12", + .class = _timer_hwmod_class, + .clkdm_name = "wkupaon_clkdm", + .main_clk = "secure_32k_clk_src_ck", + .prcm = { + .omap4 = { + .clkctrl_offs = DRA7XX_CM_WKUPAON_TIMER12_CLKCTRL_OFFSET, + .context_offs = DRA7XX_RM_WKUPAON_TIMER12_CONTEXT_OFFSET, + }, + }, +}; + /* timer13 */ static struct omap_hwmod dra7xx_timer13_hwmod = { .name = "timer13", @@ -3135,6 +3149,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer11 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l4_wkup -> timer12 */ +static struct omap_hwmod_ocp_if dra7xx_l4_wkup__timer12 = { + .master = _l4_wkup_hwmod, + .slave = _timer12_hwmod, + .clk= "wkupaon_iclk_mux", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + /* l4_per3 -> timer13 */ static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer13 = { .master = _l4_per3_hwmod, @@ -3429,6 +3451,13 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { NULL, }; +/* GP-only hwmod links */ +static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = { + _l4_wkup__timer12, + NULL, +}; + +/* SoC variant specific hwmod links */ static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = { _l4_per3__usb_otg_ss4, NULL, @@ -3446,9 +3475,12 @@ int __init dra7xx_hwmod_init(void) ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs); if (!ret && soc_is_dra74x()) - return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs); + ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs); else if (!ret && soc_is_dra72x()) - return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs); + ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs); + + if (!ret && omap_type() == OMAP2_DEVICE_TYPE_GP) + ret = omap_hwmod_register_links(dra7xx_gp_hwmod_ocp_ifs); return ret; } -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
Tony, On 10/03/2015 12:29 PM, kbuild test robot wrote: > Hi Suman, > > [auto build test results on v4.3-rc3 -- if it's inappropriate base, please > ignore] > > config: arm-omap1_defconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=arm > > All error/warnings (new ones prefixed by >>): > >arch/arm/plat-omap/dmtimer.c: In function 'omap_dm_timer_set_source': >>> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of function >>> 'clk_hw_get_num_parents' [-Werror=implicit-function-declaration] > if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) > ^ >>> arch/arm/plat-omap/dmtimer.c:509:2: error: implicit declaration of function >>> '__clk_get_hw' [-Werror=implicit-function-declaration] >cc1: some warnings being treated as errors > > vim +/clk_hw_get_num_parents +509 arch/arm/plat-omap/dmtimer.c > >503return pdata->set_timer_src(timer->pdev, > source); >504 >505if (IS_ERR(timer->fclk)) >506return -EINVAL; >507 >508/* Check if the clock has parents if not no point > checking */ > > 509if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) >510return 0; CONFIG_COMMON_CLK is not defined for OMAP1. So, are you ok if I enclose this within #ifdef CONFIG_COMMON_CLK? 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: [PATCH] clk: ti: dflt: fix enable_reg validity check
On 10/02/2015 01:21 PM, Stephen Boyd wrote: > On 09/29, Suman Anna wrote: >> diff --git a/drivers/clk/ti/clkt_dflt.c b/drivers/clk/ti/clkt_dflt.c >> index 90d7d8a21c49..1ddc288fce4e 100644 >> --- a/drivers/clk/ti/clkt_dflt.c >> +++ b/drivers/clk/ti/clkt_dflt.c >> @@ -222,7 +222,7 @@ int omap2_dflt_clk_enable(struct clk_hw *hw) >> } >> } >> >> -if (unlikely(!clk->enable_reg)) { >> +if (unlikely(IS_ERR(clk->enable_reg))) { > > IS_ERR() already has an unlikely inside it, so the unlikely is > redundant here. Thanks Stephen, didn't realize that. I will fix this up in a subsequent patch, Tero has already staged it and sent a PULL request. 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
[REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node
The DSP_SYSTEM sub-module is a dedicated system control logic module present within a DRA7 DSP processor sub-system. This module is responsible for power management, clock generation and connection to the device PRCM module. Add a syscon node for this module for the DSP1 processor sub-system. This is added as a syscon node as it is a common configuration module that can be used by the different IOMMU instances and the corresponding remoteproc device. The node is added to the common dra7.dtsi file, as the DSP1 processor sub-system is mostly common across all the variants of the DRA7 SoC family. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra7.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index e289c706d27d..62055094e8d5 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -292,6 +292,11 @@ #thermal-sensor-cells = <1>; }; + dsp1_system: dsp_system@40d0 { + compatible = "syscon"; + reg = <0x40d0 0x100>; + }; + sdma: dma-controller@4a056000 { compatible = "ti,omap4430-sdma"; reg = <0x4a056000 0x1000>; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCH 3/4] ARM: dts: DRA7: Add common IOMMU nodes
The DRA7xx family of SOCs have two IPUs and one DSP processor subsystems in common. The IOMMU DT nodes have been added for these processor subsystems, and have been disabled by default. These MMUs are very similar to those on OMAP4 and OMAP5, with the only difference being the presence of a second MMU within the DSP subsystem for the EDMA port. The DSP IOMMUs also need an additional 'ti,syscon-mmuconfig' property compared to the IPU IOMMUs. NOTE: The enabling of these nodes is left to the respective board dts files. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra7.dtsi | 40 1 file changed, 40 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 62055094e8d5..9f6bafcad385 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -916,6 +916,46 @@ status = "disabled"; }; + mmu0_dsp1: mmu@40d01000 { + compatible = "ti,dra7-dsp-iommu"; + reg = <0x40d01000 0x100>; + interrupts = ; + ti,hwmods = "mmu0_dsp1"; + #iommu-cells = <0>; + ti,syscon-mmuconfig = <_system 0x0>; + status = "disabled"; + }; + + mmu1_dsp1: mmu@40d02000 { + compatible = "ti,dra7-dsp-iommu"; + reg = <0x40d02000 0x100>; + interrupts = ; + ti,hwmods = "mmu1_dsp1"; + #iommu-cells = <0>; + ti,syscon-mmuconfig = <_system 0x1>; + status = "disabled"; + }; + + mmu_ipu1: mmu@58882000 { + compatible = "ti,dra7-iommu"; + reg = <0x58882000 0x100>; + interrupts = ; + ti,hwmods = "mmu_ipu1"; + #iommu-cells = <0>; + ti,iommu-bus-err-back; + status = "disabled"; + }; + + mmu_ipu2: mmu@55082000 { + compatible = "ti,dra7-iommu"; + reg = <0x55082000 0x100>; + interrupts = ; + ti,hwmods = "mmu_ipu2"; + #iommu-cells = <0>; + ti,iommu-bus-err-back; + status = "disabled"; + }; + abb_mpu: regulator-abb-mpu { compatible = "ti,abb-v3"; regulator-name = "abb_mpu"; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCH 4/4] ARM: dts: DRA74x: Add IOMMU nodes for DSP2
The DRA74x family of SoCs have a second DSP, that also has two MMUs just like the DSP1 subsystem. Add the IOMMU nodes for this DSP2 subsystem in disabled state to the DRA74x specific DTS file, the nodes would need to be enabled appropriately in the respective board DTS files. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra74x.dtsi | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi index dfa29b7ba86a..2f7d313e91a0 100644 --- a/arch/arm/boot/dts/dra74x.dtsi +++ b/arch/arm/boot/dts/dra74x.dtsi @@ -81,6 +81,26 @@ dr_mode = "otg"; }; }; + + mmu0_dsp2: mmu@41501000 { + compatible = "ti,dra7-dsp-iommu"; + reg = <0x41501000 0x100>; + interrupts = ; + ti,hwmods = "mmu0_dsp2"; + #iommu-cells = <0>; + ti,syscon-mmuconfig = <_system 0x0>; + status = "disabled"; + }; + + mmu1_dsp2: mmu@41502000 { + compatible = "ti,dra7-dsp-iommu"; + reg = <0x41502000 0x100>; + interrupts = ; + ti,hwmods = "mmu1_dsp2"; + #iommu-cells = <0>; + ti,syscon-mmuconfig = <_system 0x1>; + status = "disabled"; + }; }; }; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCH 2/4] ARM: dts: DRA74x: Add dsp2_system syscon node
The DSP_SYSTEM sub-module is a dedicated system control logic module present within a DRA7 DSP processor sub-system. This module is responsible for power management, clock generation and connection to the device PRCM module. Add a syscon node for this module for the DSP2 processor sub-system. This is added as a syscon node as it is a common configuration module that can be used by the different IOMMU instances and the corresponding remoteproc device. The node is added to the dra74x.dtsi file, as the DSP2 processor subsystem is usually present only on the DRA74x variants of the DRA7 SoC family. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra74x.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi index feea98e0a4b5..dfa29b7ba86a 100644 --- a/arch/arm/boot/dts/dra74x.dtsi +++ b/arch/arm/boot/dts/dra74x.dtsi @@ -52,6 +52,11 @@ }; ocp { + dsp2_system: dsp_system@4150 { + compatible = "syscon"; + reg = <0x4150 0x100>; + }; + omap_dwc3_4: omap_dwc3_4@4894 { compatible = "ti,dwc3"; ti,hwmods = "usb_otg_ss4"; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCH 0/4] Add DRA7 IOMMU DT nodes
Hi Tony, The following series is a repost of the previous seried that added the basic DT nodes for the DSP and IPU IOMMU devices for the DRA7xx SoC family [1]. There are no code changes, but the patches have to be rebased to resolve slight merge conflicts as the dra7_ctrl_core and dra7_ctrl_general nodes have been removed since the last submission. This patch series is pending based on the equivalent bindings update series [2] which has also been reposted without any changes. Patches are based on 4.3-rc3. regards Suman [1] http://marc.info/?l=linux-omap=143752332808524=2 [2] http://marc.info/?l=linux-omap=144382697928741=2 Suman Anna (4): ARM: dts: DRA7: Add dsp1_system syscon node ARM: dts: DRA74x: Add dsp2_system syscon node ARM: dts: DRA7: Add common IOMMU nodes ARM: dts: DRA74x: Add IOMMU nodes for DSP2 arch/arm/boot/dts/dra7.dtsi | 45 +++ arch/arm/boot/dts/dra74x.dtsi | 25 2 files changed, 70 insertions(+) -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCH 1/2] Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs
The DSP processor sub-systems on DRA7xx have two MMU instances each, one for the processor core and the other for an internal EDMA block. These MMUs need an additional shared register to be programmed in the DSP_SYSTEM sub-module to be enabled properly. The OMAP IOMMU bindings is updated to account for this additional syscon property required for these DSP IOMMU instances on DRA7xx SoCs. A new compatible "ti,dra7-dsp-iommu" is also defined to distinguish these devices specifically from other DRA7 IOMMU devices. An example of the DRA7 DSP IOMMU nodes is also added to the document for clarity. Signed-off-by: Suman Anna <s-a...@ti.com> --- .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++ 1 file changed, 27 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt index 869699925fd5..4bd10dd881b8 100644 --- a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -4,6 +4,7 @@ Required properties: - compatible : Should be one of, "ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances "ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances + "ti,dra7-dsp-iommu" for DRA7xx DSP IOMMU instances "ti,dra7-iommu" for DRA7xx IOMMU instances - ti,hwmods : Name of the hwmod associated with the IOMMU instance - reg: Address space for the configuration registers @@ -19,6 +20,13 @@ Optional properties: Should be either 8 or 32 (default: 32) - ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing back a bus error response on MMU faults. +- ti,syscon-mmuconfig : Should be a pair of the phandle to the DSP_SYSTEM +syscon node that contains the additional control +register for enabling the MMU, and the MMU instance +number (0-indexed) within the sub-system. This property +is required for DSP IOMMU instances on DRA7xx SoCs. The +instance number should be 0 for DSP MDMA MMUs and 1 for +DSP EDMA MMUs. Example: /* OMAP3 ISP MMU */ @@ -30,3 +38,22 @@ Example: ti,hwmods = "mmu_isp"; ti,#tlb-entries = <8>; }; + + /* DRA74x DSP2 MMUs */ + mmu0_dsp2: mmu@41501000 { + compatible = "ti,dra7-dsp-iommu"; + reg = <0x41501000 0x100>; + interrupts = ; + ti,hwmods = "mmu0_dsp2"; + #iommu-cells = <0>; + ti,syscon-mmuconfig = <_system 0x0>; + }; + + mmu1_dsp2: mmu@41502000 { + compatible = "ti,dra7-dsp-iommu"; + reg = <0x41502000 0x100>; + interrupts = ; + ti,hwmods = "mmu1_dsp2"; + #iommu-cells = <0>; + ti,syscon-mmuconfig = <_system 0x1>; + }; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REPOST PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx
The DSP MMUs on DRA7xx SoC requires configuring an additional MMU_CONFIG register present in the DSP_SYSTEM sub module. This setting dictates whether the DSP Core's MDMA and EDMA traffic is routed through the respective MMU or not. Add the support to the OMAP iommu driver so that the traffic is not bypassed when enabling the MMUs. The MMU_CONFIG register has two different bits for enabling each of these two MMUs present in the DSP processor sub-system on DRA7xx. An id field is added to the OMAP iommu object to identify and enable each IOMMU. The id information and the DSP_SYSTEM.MMU_CONFIG register programming is achieved through the processing of the optional "ti,syscon-mmuconfig" property. A proper value is assigned to the id field only when this property is present. Signed-off-by: Suman Anna <s-a...@ti.com> --- drivers/iommu/omap-iommu.c | 58 ++ drivers/iommu/omap-iommu.h | 9 +++ 2 files changed, 67 insertions(+) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 36d0033c2ccb..3dc5b65f3990 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -26,6 +26,8 @@ #include #include #include +#include +#include #include @@ -112,6 +114,18 @@ void omap_iommu_restore_ctx(struct device *dev) } EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx); +static void dra7_cfg_dspsys_mmu(struct omap_iommu *obj, bool enable) +{ + u32 val, mask; + + if (!obj->syscfg) + return; + + mask = (1 << (obj->id * DSP_SYS_MMU_CONFIG_EN_SHIFT)); + val = enable ? mask : 0; + regmap_update_bits(obj->syscfg, DSP_SYS_MMU_CONFIG, mask, val); +} + static void __iommu_set_twl(struct omap_iommu *obj, bool on) { u32 l = iommu_read_reg(obj, MMU_CNTL); @@ -147,6 +161,8 @@ static int omap2_iommu_enable(struct omap_iommu *obj) iommu_write_reg(obj, pa, MMU_TTB); + dra7_cfg_dspsys_mmu(obj, true); + if (obj->has_bus_err_back) iommu_write_reg(obj, MMU_GP_REG_BUS_ERR_BACK_EN, MMU_GP_REG); @@ -161,6 +177,7 @@ static void omap2_iommu_disable(struct omap_iommu *obj) l &= ~MMU_CNTL_MASK; iommu_write_reg(obj, l, MMU_CNTL); + dra7_cfg_dspsys_mmu(obj, false); dev_dbg(obj->dev, "%s is shutting down\n", obj->name); } @@ -864,6 +881,42 @@ static void omap_iommu_detach(struct omap_iommu *obj) dev_dbg(obj->dev, "%s: %s\n", __func__, obj->name); } +static int omap_iommu_dra7_get_dsp_system_cfg(struct platform_device *pdev, + struct omap_iommu *obj) +{ + struct device_node *np = pdev->dev.of_node; + int ret; + + if (!of_device_is_compatible(np, "ti,dra7-dsp-iommu")) + return 0; + + if (!of_property_read_bool(np, "ti,syscon-mmuconfig")) { + dev_err(>dev, "ti,syscon-mmuconfig property is missing\n"); + return -EINVAL; + } + + obj->syscfg = + syscon_regmap_lookup_by_phandle(np, "ti,syscon-mmuconfig"); + if (IS_ERR(obj->syscfg)) { + /* can fail with -EPROBE_DEFER */ + ret = PTR_ERR(obj->syscfg); + return ret; + } + + if (of_property_read_u32_index(np, "ti,syscon-mmuconfig", 1, + >id)) { + dev_err(>dev, "couldn't get the IOMMU instance id within subsystem\n"); + return -EINVAL; + } + + if (obj->id != 0 && obj->id != 1) { + dev_err(>dev, "invalid IOMMU instance id\n"); + return -EINVAL; + } + + return 0; +} + /* * OMAP Device MMU(IOMMU) detection */ @@ -907,6 +960,10 @@ static int omap_iommu_probe(struct platform_device *pdev) if (IS_ERR(obj->regbase)) return PTR_ERR(obj->regbase); + err = omap_iommu_dra7_get_dsp_system_cfg(pdev, obj); + if (err) + return err; + irq = platform_get_irq(pdev, 0); if (irq < 0) return -ENODEV; @@ -943,6 +1000,7 @@ static const struct of_device_id omap_iommu_of_match[] = { { .compatible = "ti,omap2-iommu" }, { .compatible = "ti,omap4-iommu" }, { .compatible = "ti,dra7-iommu" }, + { .compatible = "ti,dra7-dsp-iommu" }, {}, }; diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h index a656df2f9e03..59628e5017b4 100644 --- a/drivers/iommu/omap-iommu.h +++ b/drivers/iommu/omap-iommu.h @@ -30,6 +30,7 @@ struct iotlb_entry { struct omap_iommu { const char *name; void __iomem*regbase; + struct regmap *syscfg; struct device *dev; struct iommu_domain *domain; struct
[REPOST PATCH 0/2] DRA7 DSP MMU config support
Hi Joerg, This is a repost of the DRA7 DSP MMU config support patch series, baselined on the latest rc (4.3-rc3). Details of the MMUs are summarized in the previous series [1], and the discussion with Tony did not require any changes to the code from that series. As per your request, I have also summarized the testing details below. I have tested the patches on OMAP3 Beagle-XM, OMAP4 Panda Board, OMAP5 uEVM and DRA7 Beagle-X15 boards using a OMAP IOMMU unit test module [2]. The unit test basically requires a test node to be added to the respective nodes with it using the IOMMU under test. The test is done during the probe of the test platform driver, with it mainly attaching to the IOMMU and programming the MMU pagetable. The entire test branch is hosted [3] for your reference and the corresponding logs are at [4]. A few additional notes regarding testing: - OMAP3 IVA MMU node was disabled at the moment in kernel, so it had to be enabled in the test branch along with the test node. A fix [5] was required in the TI CLK driver for it to pass the test, and this fix will be incorporated into the current -rc cycle. - One MMU device is tested per boot, depending on the IOMMU used by the test node. - This is only a preparatory series in adding the IOMMU support for the DRA7 SoCs. Full enablement of DRA7 IOMMUs requires DTS nodes, hwmod data and pdata quirks needed for reset management. The DRA7 logs therefore do not list any MMUs and the OMAP IOMMU driver is not registered even due to the absence of any compatible DT nodes. This series also had a supplementary DTS patch series previously [6], and I will be reposting those as well after rebasing for Tony to pick them up through the linux-omap tree. regards Suman [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013704.html [2] https://github.com/sumananna/omap-test-iommu/blob/master/main_dt.c [3] https://github.com/sumananna/omap-kernel/commits/iommu/test/4.3-rc3-dra7-dsp-support [4] https://github.com/sumananna/kernel-test-logs/tree/master/4.3-rc3-dra7-dsp-support [5] http://marc.info/?l=linux-omap=144356627831318=2 [6] http://marc.info/?l=linux-omap=143752332808524=2 Suman Anna (2): Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs iommu/omap: Add support for configuring dsp iommus on DRA7xx .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++ drivers/iommu/omap-iommu.c | 58 ++ drivers/iommu/omap-iommu.h | 9 3 files changed, 94 insertions(+) -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
The omap_dm_timer_set_source() function provides a means for client users to configure the mux parent for a GPTimer's functional clock. However, not all timers are configurable (Eg: Timer12 on DRA7 is fed by an internal 32k oscillator clock, and does not have configurable parent clocks). So, check for such cases and proceed with out throwing an error. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/plat-omap/dmtimer.c | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 8ca94d379bc3..25693e722f1f 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -36,6 +36,7 @@ */ #include +#include #include #include #include @@ -504,6 +505,10 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer, int source) if (IS_ERR(timer->fclk)) return -EINVAL; + /* Check if the clock has parents if not no point checking */ + if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk))) + return 0; + switch (source) { case OMAP_TIMER_SRC_SYS_CLK: parent_name = "timer_sys_ck"; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] DRA7 Timer12 Support
Hi Tony, The DRA7 Timer12 is completely missing from the kernel. This series adds the support for it, so that all the Timers on DRA7 are represented in the kernel. Timer12 is a special Timer, and is not available for kernel on HS devices, very much similar to the equivalent timer on OMAP3. Patch 1 is a bit debatable, as I am not entirely sure if the clk API used are acceptable outside the drivers/clk folders. It keeps intact the omap_dm_timer_set_source() API though, and allows it to handle the non-configurability of Timer12 parent within that API. The need for this API is questionable, I am not a big fan as the dmtimer code blindly tries to set the source of every requested API to OMAP_TIMER_SRC_32_KHZ, and then the requestors would have to reset the proper parent source again. It also supports configuring only one of 3 parents (which are valid when added originally for the then SoCs), requiring specific clock aliases to work across different SoCs, but the DRA7 SoC does have more than 3 configurable clock parents, and the indexes may not necessarily match for different timers on different SoCs. Patch 1 won't be needed if we can kill the omap_dm_timer_set_source() API. Patches baselined on 4.3-rc3, but should apply just fine on -rc1 as well. regards Suman Suman Anna (4): ARM: OMAP: dmtimer: check for fixed timers during config ARM: OMAP2+: timer: Remove secure timer for DRA7xx devices ARM: dts: DRA7: Add timer12 node ARM: DRA7: hwmod: Add data for GPTimer 12 arch/arm/boot/dts/dra7.dtsi | 10 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +-- arch/arm/mach-omap2/timer.c | 6 +++--- arch/arm/plat-omap/dmtimer.c | 5 + 4 files changed, 52 insertions(+), 5 deletions(-) -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP2+: timer: Remove secure timer for DRA7xx devices
Timer 12 on DRA7 SoCs is reserved for secure usage on high-secure (HS) devices. The timer cannot be used by the kernel on HS devices, but is available on regular general purpose (GP) devices. This is similar to the behavior on OMAP3 devices, so extend the logic used in commit ad24bde8f102 ("ARM: OMAP3: Dynamically disable secure timer nodes for secure devices") to remove the secure timer on DRA7xx SoCs at run-time based on the SoC device type. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/timer.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index a55655127ef2..1e346aa0a687 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -193,8 +193,8 @@ static struct device_node * __init omap_get_timer_dt(const struct of_device_id * /** * omap_dmtimer_init - initialisation function when device tree is used * - * For secure OMAP3 devices, timers with device type "timer-secure" cannot - * be used by the kernel as they are reserved. Therefore, to prevent the + * For secure OMAP3/DRA7xx devices, timers with device type "timer-secure" + * cannot be used by the kernel as they are reserved. Therefore, to prevent the * kernel registering these devices remove them dynamically from the device * tree on boot. */ @@ -202,7 +202,7 @@ static void __init omap_dmtimer_init(void) { struct device_node *np; - if (!cpu_is_omap34xx()) + if (!cpu_is_omap34xx() && !soc_is_dra7xx()) return; /* If we are a secure device, remove any secure timer nodes */ -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: DRA7: hwmod: Add data for GPTimer 12
Add the hwmod data for GPTimer 12. GPTimer 12 is present in WKUPAON power domain and is clocked from a secure 32K clock. GPTimer 12 serves as a secure timer on HS devices, but is available for kernel on regular GP devices. The hwmod link is registered only on GP devices. The hwmod data also reused the existing timer class instead of reintroducing the identical dra7xx_timer_secure_sysc class which was dropped in commit edec17863362 ("ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4"). Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +-- 1 file changed, 34 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c index 562247bced49..37a10f87fbcd 100644 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c @@ -1929,6 +1929,20 @@ static struct omap_hwmod dra7xx_timer11_hwmod = { }, }; +/* timer12 */ +static struct omap_hwmod dra7xx_timer12_hwmod = { + .name = "timer12", + .class = _timer_hwmod_class, + .clkdm_name = "wkupaon_clkdm", + .main_clk = "secure_32k_clk_src_ck", + .prcm = { + .omap4 = { + .clkctrl_offs = DRA7XX_CM_WKUPAON_TIMER12_CLKCTRL_OFFSET, + .context_offs = DRA7XX_RM_WKUPAON_TIMER12_CONTEXT_OFFSET, + }, + }, +}; + /* timer13 */ static struct omap_hwmod dra7xx_timer13_hwmod = { .name = "timer13", @@ -3135,6 +3149,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer11 = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; +/* l4_wkup -> timer12 */ +static struct omap_hwmod_ocp_if dra7xx_l4_wkup__timer12 = { + .master = _l4_wkup_hwmod, + .slave = _timer12_hwmod, + .clk= "wkupaon_iclk_mux", + .user = OCP_USER_MPU | OCP_USER_SDMA, +}; + /* l4_per3 -> timer13 */ static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer13 = { .master = _l4_per3_hwmod, @@ -3429,6 +3451,13 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = { NULL, }; +/* GP-only hwmod links */ +static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = { + _l4_wkup__timer12, + NULL, +}; + +/* SoC variant specific hwmod links */ static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = { _l4_per3__usb_otg_ss4, NULL, @@ -3446,9 +3475,12 @@ int __init dra7xx_hwmod_init(void) ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs); if (!ret && soc_is_dra74x()) - return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs); + ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs); else if (!ret && soc_is_dra72x()) - return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs); + ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs); + + if (!ret && omap_type() == OMAP2_DEVICE_TYPE_GP) + ret = omap_hwmod_register_links(dra7xx_gp_hwmod_ocp_ifs); return ret; } -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: DRA7: Add timer12 node
Add the DT node for Timer12 present on DRA7 family of SoCs. Timer12 is present in PD_WKUPAON power domain, and has the same capabilities as the other timers, except for the fact that it serves as a secure timer on HS devices and is clocked only from the secure 32K clock. The node is marked disabled for now, and the kernel should refrain from using this secure timer on HS devices. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra7.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index e289c706d27d..37d632dad576 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -762,6 +762,16 @@ ti,hwmods = "timer11"; }; + timer12: timer@4ae2 { + compatible = "ti,omap5430-timer"; + reg = <0x4ae2 0x80>; + interrupts = ; + ti,hwmods = "timer12"; + ti,timer-alwon; + ti,timer-secure; + status = "disabled"; + }; + timer13: timer@48828000 { compatible = "ti,omap5430-timer"; reg = <0x48828000 0x80>; -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] clk: ti: dflt: fix enable_reg validity check
The default clock enabling functions for TI clocks - omap2_dflt_clk_enable() and omap2_dflt_clk_disable() perform a NULL check for the enable_reg field of the clk_hw_omap structure. This enable_reg field however is merely a combination of the index of the master IP module, and the offset from the master IP module's base address. A value of 0 is perfectly valid, and the current error checking will fail in these cases. The issue was found when trying to enable the iva2_ck clock on OMAP3 platforms. So, switch the check to use IS_ERR. This correction is similar to the logic used in commit c807dbedb5e5 ("clk: ti: fix ti_clk_get_reg_addr error handling"). Signed-off-by: Suman Anna <s-a...@ti.com> --- Hi Tero, Patch done against 4.3-rc3. There are couple of similar checks in drivers/clk/ti/clockdomain.c, but those seem to be ok. This is a non-urgent fix, as there are currently no active users of iva2_ck in the kernel (the MMU node is disabled in DT atm). Boot tested on OMAP3 Beagle-XM, AM437x GP EVM, AM335x BeagleBone Black, OMAP4 Panda, OMAP5 uEVM and DRA7 Beagle-X15 boards. regards Suman Following is the error log from a unit test of the IVA MMU on OMAP3 using some additional patch to enable the DTS node, [ 86.626342] omap_iommu_test_init: iommu_test_init entered [ 86.632080] omap_iommu_test iommu_test: Enabling IOMMU... [ 86.647460] omap_iommu_test iommu_test: testing IOMMU 5d00.mmu [ 86.654815] omap2_dflt_clk_enable: iva2_ck missing enable_reg [ 86.680938] [ cut here ] [ 86.685821] WARNING: CPU: 0 PID: 910 at drivers/clk/clk.c:675 clk_disable+0x28/0x34() [ 86.694091] Modules linked in: iommu_dt_test(O+) [ 86.698974] CPU: 0 PID: 910 Comm: insmod Tainted: G O 4.3.0-rc3-8-g61458979cbbe #40 [ 86.708618] Hardware name: Generic OMAP36xx (Flattened Device Tree) [ 86.715240] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 86.723419] [] (show_stack) from [] (dump_stack+0x84/0x9c) [ 86.731048] [] (dump_stack) from [] (warn_slowpath_common+0x78/0xb4) [ 86.739593] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [ 86.748870] [] (warn_slowpath_null) from [] (clk_disable+0x28/0x34) [ 86.757324] [] (clk_disable) from [] (_disable_clocks+0x18/0x68) [ 86.765502] [] (_disable_clocks) from [] (omap_hwmod_deassert_hardreset+0xc8/0x180) [ 86.775421] [] (omap_hwmod_deassert_hardreset) from [] (omap_device_deassert_hardreset+0x34/ 0x54) [ 86.786621] [] (omap_device_deassert_hardreset) from [] (omap_iommu_attach_dev+0xbc/0x1fc) [ 86.797180] [] (omap_iommu_attach_dev) from [] (__iommu_attach_device+0x1c/0x80) [ 86.806854] [] (__iommu_attach_device) from [] (omap_iommu_test_probe+0xd0/0x21c [iommu_dt_t est]) [ 86.818054] [] (omap_iommu_test_probe [iommu_dt_test]) from [] (platform_drv_probe+0x44/0xa4 ) [ 86.828857] [] (platform_drv_probe) from [] (driver_probe_device+0x1f4/0x2f0) [ 86.838195] [] (driver_probe_device) from [] (__driver_attach+0x94/0x98) [ 86.847045] [] (__driver_attach) from [] (bus_for_each_dev+0x6c/0xa0) [ 86.855651] [] (bus_for_each_dev) from [] (bus_add_driver+0x18c/0x214) [ 86.864349] [] (bus_add_driver) from [] (driver_register+0x78/0xf8) [ 86.872772] [] (driver_register) from [] (do_one_initcall+0x80/0x1dc) [ 86.881378] [] (do_one_initcall) from [] (do_init_module+0x5c/0x1d0) [ 86.889892] [] (do_init_module) from [] (load_module+0x1818/0x1f70) [ 86.898315] [] (load_module) from [] (SyS_init_module+0xdc/0x14c) [ 86.906555] [] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x1c) [ 86.915039] ---[ end trace 49b229a4289ab8b2 ]--- [ 86.919891] omap_hwmod: mmu_iva: failed to hardreset [ 86.925384] omap-iommu 5d00.mmu: deassert_reset failed: -16 [ 86.931640] omap_iommu_test iommu_test: can't get omap iommu: -16 [ 86.938140] omap_iommu_test iommu_test: can't attach iommu device: -16 [ 86.945068] omap_iommu_test_init failed, ret = -16 drivers/clk/ti/clkt_dflt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/clk/ti/clkt_dflt.c b/drivers/clk/ti/clkt_dflt.c index 90d7d8a21c49..1ddc288fce4e 100644 --- a/drivers/clk/ti/clkt_dflt.c +++ b/drivers/clk/ti/clkt_dflt.c @@ -222,7 +222,7 @@ int omap2_dflt_clk_enable(struct clk_hw *hw) } } - if (unlikely(!clk->enable_reg)) { + if (unlikely(IS_ERR(clk->enable_reg))) { pr_err("%s: %s missing enable_reg\n", __func__, clk_hw_get_name(hw)); ret = -EINVAL; @@ -264,7 +264,7 @@ void omap2_dflt_clk_disable(struct clk_hw *hw) u32 v; clk = to_clk_hw_omap(hw); - if (!clk->enable_reg) { + if (IS_ERR(clk->enable_reg)) { /* * 'independent' here refers to a clock which is not * controlled by its parent. -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe lin
[PATCH 5/5] ARM: dts: beagle-x15: Enable the system mailboxes 5 and 6
Enable the System Mailboxes 5 and 6 and the corresponding child sub-mailbox (IPC 3.x) nodes for the Beagle X15 EVM boards. This is needed to enable communication with the respective remote processors IPU1, IPU2, DSP1 and DSP2 from the MPU. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/am57xx-beagle-x15.dts | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts b/arch/arm/boot/dts/am57xx-beagle-x15.dts index 3a05b94f59ed..4a13419ab025 100644 --- a/arch/arm/boot/dts/am57xx-beagle-x15.dts +++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts @@ -696,3 +696,23 @@ { gpios = < 8 GPIO_ACTIVE_LOW>; }; + + { + status = "okay"; + mbox_ipu1_ipc3x: mbox_ipu1_ipc3x { + status = "okay"; + }; + mbox_dsp1_ipc3x: mbox_dsp1_ipc3x { + status = "okay"; + }; +}; + + { + status = "okay"; + mbox_ipu2_ipc3x: mbox_ipu2_ipc3x { + status = "okay"; + }; + mbox_dsp2_ipc3x: mbox_dsp2_ipc3x { + status = "okay"; + }; +}; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: dts: dra72-evm: Enable the system mailboxes 5 and 6
Enable the System Mailboxes 5 and 6 and the corresponding child sub-mailbox (IPC 3.x) nodes for the DRA72 EVM board. This is needed to enable communication with the respective remote processors IPU1, IPU2, and DSP1 from the MPU. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra72-evm.dts | 17 + 1 file changed, 17 insertions(+) diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts index 6f6bd98c98df..ccb535b5ef9b 100644 --- a/arch/arm/boot/dts/dra72-evm.dts +++ b/arch/arm/boot/dts/dra72-evm.dts @@ -695,3 +695,20 @@ }; }; }; + + { + status = "okay"; + mbox_ipu1_ipc3x: mbox_ipu1_ipc3x { + status = "okay"; + }; + mbox_dsp1_ipc3x: mbox_dsp1_ipc3x { + status = "okay"; + }; +}; + + { + status = "okay"; + mbox_ipu2_ipc3x: mbox_ipu2_ipc3x { + status = "okay"; + }; +}; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: dts: dra7-evm: Enable the system mailboxes 5 and 6
Enable the System Mailboxes 5 and 6 and the corresponding child sub-mailbox (IPC 3.x) nodes for the DRA7 EVM board. This is needed to enable communication with the respective remote processors IPU1, IPU2, DSP1 and DSP2 from the MPU. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra7-evm.dts | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index a6c82e5b64fe..718315ac3063 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -707,3 +707,23 @@ pinctrl-1 = <_pins_sleep>; pinctrl-2 = <_pins_default>; }; + + { + status = "okay"; + mbox_ipu1_ipc3x: mbox_ipu1_ipc3x { + status = "okay"; + }; + mbox_dsp1_ipc3x: mbox_dsp1_ipc3x { + status = "okay"; + }; +}; + + { + status = "okay"; + mbox_ipu2_ipc3x: mbox_ipu2_ipc3x { + status = "okay"; + }; + mbox_dsp2_ipc3x: mbox_dsp2_ipc3x { + status = "okay"; + }; +}; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] Add DRA7 sub-mailboxes for 4.4
Hi Tony, This series adds the sub-mailbox nodes and enable them for each of the TI DRA7 boards. These are the basic mailbox configuration nodes required by client users (remoteproc) to communicate with the various IPU and DSP processor devices on DRA74x and DRA72x SoCs using the TI IPC 3.x software foundation on the remote processor firmwares. The mailboxes used are unfortunately hardcoded in the TI IPC 3.x software, and hence the weird usage of Mailbox 5 and 6 rather than starting from Mailbox 1. Any third-party or derived boards can use their own configuration if running their own IPC stack, and that can be done by overwriting the properties or by using different sub-mailbox nodes altogether. The actual enablement of nodes is therefore done in the respective board DTS files. Patches are based on 4.3-rc1 and are intended for the 4.4 merge window. regards Suman Suman Anna (5): ARM: dts: DRA74x: Add IPC sub-mailbox nodes for all IPUs & DSPs ARM: dts: DRA72x: Add IPC sub-mailbox nodes for IPU1, IPU2 & DSP1 ARM: dts: dra7-evm: Enable the system mailboxes 5 and 6 ARM: dts: dra72-evm: Enable the system mailboxes 5 and 6 ARM: dts: beagle-x15: Enable the system mailboxes 5 and 6 arch/arm/boot/dts/am57xx-beagle-x15.dts | 20 arch/arm/boot/dts/dra7-evm.dts | 20 arch/arm/boot/dts/dra72-evm.dts | 17 + arch/arm/boot/dts/dra72x.dtsi | 21 + arch/arm/boot/dts/dra74x.dtsi | 26 ++ 5 files changed, 104 insertions(+) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: dts: DRA72x: Add IPC sub-mailbox nodes for IPU1, IPU2 & DSP1
Add the sub-mailbox nodes that are used to communicate between MPU and the remote processors IPU1, IPU2 and DSP1. These match the respective node definitions on DRA74x to maintain compatibility for the equivalent remote processors. There is no DSP2 on DRA72x, and so the corresponding sub-mailbox node is not added. These sub-mailbox nodes are added to match the hard-coded mailbox configuration used within the TI IPC 3.x software package. The Dual-Cortex M4 IPU1 and IPU2 processor sub-systems are assumed to be running in SMP-mode, and hence only a single sub-mailbox node is added for each. All these sub-mailbox nodes are left in disabled state, and should be enabled (and modified if needed) as per the individual product configuration in the corresponding board dts files. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra72x.dtsi | 21 + 1 file changed, 21 insertions(+) diff --git a/arch/arm/boot/dts/dra72x.dtsi b/arch/arm/boot/dts/dra72x.dtsi index eaca143faa77..70a217050a4c 100644 --- a/arch/arm/boot/dts/dra72x.dtsi +++ b/arch/arm/boot/dts/dra72x.dtsi @@ -45,3 +45,24 @@ <_video1_clk>; clock-names = "fck", "video1_clk"; }; + + { + mbox_ipu1_ipc3x: mbox_ipu1_ipc3x { + ti,mbox-tx = <6 2 2>; + ti,mbox-rx = <4 2 2>; + status = "disabled"; + }; + mbox_dsp1_ipc3x: mbox_dsp1_ipc3x { + ti,mbox-tx = <5 2 2>; + ti,mbox-rx = <1 2 2>; + status = "disabled"; + }; +}; + + { + mbox_ipu2_ipc3x: mbox_ipu2_ipc3x { + ti,mbox-tx = <6 2 2>; + ti,mbox-rx = <4 2 2>; + status = "disabled"; + }; +}; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] ARM: dts: DRA74x: Add IPC sub-mailbox nodes for all IPUs & DSPs
Add the sub-mailbox nodes that are used to communicate between MPU and the remote processors IPU1, IPU2, DSP1 and DSP2. The sub-mailbox nodes utilize the System Mailbox instances 5 and 6. These sub-mailbox nodes are added to match the hard-coded mailbox configuration used within the TI IPC 3.x software package. The Dual-Cortex M4 IPU1 and IPU2 processor sub-systems are assumed to be running in SMP-mode, and hence only a single sub-mailbox node is added for each. All these sub-mailbox nodes are left in disabled state, and should be enabled (and modified if needed) as per the individual product configuration in the corresponding board dts files. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/boot/dts/dra74x.dtsi | 26 ++ 1 file changed, 26 insertions(+) diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi index feea98e0a4b5..33d11c2c8af3 100644 --- a/arch/arm/boot/dts/dra74x.dtsi +++ b/arch/arm/boot/dts/dra74x.dtsi @@ -93,3 +93,29 @@ <_video2_clk>; clock-names = "fck", "video1_clk", "video2_clk"; }; + + { + mbox_ipu1_ipc3x: mbox_ipu1_ipc3x { + ti,mbox-tx = <6 2 2>; + ti,mbox-rx = <4 2 2>; + status = "disabled"; + }; + mbox_dsp1_ipc3x: mbox_dsp1_ipc3x { + ti,mbox-tx = <5 2 2>; + ti,mbox-rx = <1 2 2>; + status = "disabled"; + }; +}; + + { + mbox_ipu2_ipc3x: mbox_ipu2_ipc3x { + ti,mbox-tx = <6 2 2>; + ti,mbox-rx = <4 2 2>; + status = "disabled"; + }; + mbox_dsp2_ipc3x: mbox_dsp2_ipc3x { + ti,mbox-tx = <5 2 2>; + ti,mbox-rx = <1 2 2>; + status = "disabled"; + }; +}; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP2+: Remove legacy device instantiation of IOMMUs
The legacy-style IOMMU device creation is maintained currently only for OMAP3 SoC, as all other SoCs are DT-boot only, and also to ensure functionality of the OMAP3 ISP driver, the only in-kernel client user on OMAP3 that supported both modes. Commit 78c66fbcec71 ("[media] v4l: omap3isp: Drop platform data support") removed the legacy device support from the OMAP3 ISP driver, so the legacy device instantiation of OMAP IOMMU devices is no longer needed, and is cleaned up. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/omap-iommu.c | 66 1 file changed, 66 deletions(-) delete mode 100644 arch/arm/mach-omap2/omap-iommu.c diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c deleted file mode 100644 index 8867eb4025bf.. --- a/arch/arm/mach-omap2/omap-iommu.c +++ /dev/null @@ -1,66 +0,0 @@ -/* - * omap iommu: omap device registration - * - * Copyright (C) 2008-2009 Nokia Corporation - * - * Written by Hiroshi DOYU <hiroshi.d...@nokia.com> - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include -#include -#include -#include - -#include -#include "soc.h" -#include "omap_hwmod.h" -#include "omap_device.h" - -static int __init omap_iommu_dev_init(struct omap_hwmod *oh, void *unused) -{ - struct platform_device *pdev; - struct iommu_platform_data *pdata; - struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh->dev_attr; - static int i; - - pdata = kzalloc(sizeof(*pdata), GFP_KERNEL); - if (!pdata) - return -ENOMEM; - - pdata->name = oh->name; - pdata->nr_tlb_entries = a->nr_tlb_entries; - - if (oh->rst_lines_cnt == 1) { - pdata->reset_name = oh->rst_lines->name; - pdata->assert_reset = omap_device_assert_hardreset; - pdata->deassert_reset = omap_device_deassert_hardreset; - } - - pdev = omap_device_build("omap-iommu", i, oh, pdata, sizeof(*pdata)); - - kfree(pdata); - - if (IS_ERR(pdev)) { - pr_err("%s: device build err: %ld\n", __func__, PTR_ERR(pdev)); - return PTR_ERR(pdev); - } - - i++; - - return 0; -} - -static int __init omap_iommu_init(void) -{ - /* If dtb is there, the devices will be created dynamically */ - if (of_have_populated_dt()) - return -ENODEV; - - return omap_hwmod_for_each_by_class("mmu", omap_iommu_dev_init, NULL); -} -omap_subsys_initcall(omap_iommu_init); -/* must be ready before omap3isp is probed */ -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: OMAP2+: Remove omap_mmu_dev_attr structure
The structure omap_mmu_dev_attr was used in the hwmod data for supplying device-specific data through the .dev_attr field and used in constructing the platform data for legacy device creation. The legacy device creation of OMAP IOMMU devices has been cleaned up, and this structure is no longer needed, so remove it. Signed-off-by: Suman Anna <s-a...@ti.com> --- include/linux/platform_data/iommu-omap.h | 9 - 1 file changed, 9 deletions(-) diff --git a/include/linux/platform_data/iommu-omap.h b/include/linux/platform_data/iommu-omap.h index 54a0a9582fad..0496d171700a 100644 --- a/include/linux/platform_data/iommu-omap.h +++ b/include/linux/platform_data/iommu-omap.h @@ -29,15 +29,6 @@ struct omap_iommu_arch_data { struct omap_iommu *iommu_dev; }; -/** - * struct omap_mmu_dev_attr - OMAP mmu device attributes for omap_hwmod - * @nr_tlb_entries:number of entries supported by the translation - * look-aside buffer (TLB). - */ -struct omap_mmu_dev_attr { - int nr_tlb_entries; -}; - struct iommu_platform_data { const char *name; const char *reset_name; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: OMAP4: hwmod data: Remove legacy IOMMU attr and addrs
OMAP4 has been DT-boot only for some time, and the legacy-mode device creation logic for IOMMU devices has also been cleaned up, so the dev_attr and address data is no longer required. So, remove these attribute data and hwmod addr space for the IPU & DSP IOMMU devices. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 31 -- 1 file changed, 31 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 43eebf2c59e2..56586b5d6051 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -30,7 +30,6 @@ #include #include -#include #include #include "omap_hwmod.h" @@ -2088,30 +2087,16 @@ static struct omap_hwmod_class omap44xx_mmu_hwmod_class = { /* mmu ipu */ -static struct omap_mmu_dev_attr mmu_ipu_dev_attr = { - .nr_tlb_entries = 32, -}; - static struct omap_hwmod omap44xx_mmu_ipu_hwmod; static struct omap_hwmod_rst_info omap44xx_mmu_ipu_resets[] = { { .name = "mmu_cache", .rst_shift = 2 }, }; -static struct omap_hwmod_addr_space omap44xx_mmu_ipu_addrs[] = { - { - .pa_start = 0x55082000, - .pa_end = 0x550820ff, - .flags = ADDR_TYPE_RT, - }, - { } -}; - /* l3_main_2 -> mmu_ipu */ static struct omap_hwmod_ocp_if omap44xx_l3_main_2__mmu_ipu = { .master = _l3_main_2_hwmod, .slave = _mmu_ipu_hwmod, .clk= "l3_div_ck", - .addr = omap44xx_mmu_ipu_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; @@ -2130,35 +2115,20 @@ static struct omap_hwmod omap44xx_mmu_ipu_hwmod = { .modulemode = MODULEMODE_HWCTRL, }, }, - .dev_attr = _ipu_dev_attr, }; /* mmu dsp */ -static struct omap_mmu_dev_attr mmu_dsp_dev_attr = { - .nr_tlb_entries = 32, -}; - static struct omap_hwmod omap44xx_mmu_dsp_hwmod; static struct omap_hwmod_rst_info omap44xx_mmu_dsp_resets[] = { { .name = "mmu_cache", .rst_shift = 1 }, }; -static struct omap_hwmod_addr_space omap44xx_mmu_dsp_addrs[] = { - { - .pa_start = 0x4a066000, - .pa_end = 0x4a0660ff, - .flags = ADDR_TYPE_RT, - }, - { } -}; - /* l4_cfg -> dsp */ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__mmu_dsp = { .master = _l4_cfg_hwmod, .slave = _mmu_dsp_hwmod, .clk= "l4_div_ck", - .addr = omap44xx_mmu_dsp_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; @@ -2177,7 +2147,6 @@ static struct omap_hwmod omap44xx_mmu_dsp_hwmod = { .modulemode = MODULEMODE_HWCTRL, }, }, - .dev_attr = _dsp_dev_attr, }; /* -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP3: hwmod data: Remove legacy IOMMU data
The legacy-mode device creation logic for IOMMU devices has been cleaned up, so the device attribute data, irq information and address data are no longer required. Remove all of these data for the ISP & IVA IOMMU devices. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 42 -- 1 file changed, 42 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index dc55f8dedf2c..01dfccaa0c3e 100644 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -25,7 +25,6 @@ #include "l4_3xxx.h" #include #include -#include #include #include @@ -2976,80 +2975,40 @@ static struct omap_hwmod_class omap3xxx_mmu_hwmod_class = { }; /* mmu isp */ - -static struct omap_mmu_dev_attr mmu_isp_dev_attr = { - .nr_tlb_entries = 8, -}; - static struct omap_hwmod omap3xxx_mmu_isp_hwmod; -static struct omap_hwmod_irq_info omap3xxx_mmu_isp_irqs[] = { - { .irq = 24 + OMAP_INTC_START, }, - { .irq = -1 } -}; - -static struct omap_hwmod_addr_space omap3xxx_mmu_isp_addrs[] = { - { - .pa_start = 0x480bd400, - .pa_end = 0x480bd47f, - .flags = ADDR_TYPE_RT, - }, - { } -}; /* l4_core -> mmu isp */ static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmu_isp = { .master = _l4_core_hwmod, .slave = _mmu_isp_hwmod, - .addr = omap3xxx_mmu_isp_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; static struct omap_hwmod omap3xxx_mmu_isp_hwmod = { .name = "mmu_isp", .class = _mmu_hwmod_class, - .mpu_irqs = omap3xxx_mmu_isp_irqs, .main_clk = "cam_ick", - .dev_attr = _isp_dev_attr, .flags = HWMOD_NO_IDLEST, }; /* mmu iva */ -static struct omap_mmu_dev_attr mmu_iva_dev_attr = { - .nr_tlb_entries = 32, -}; - static struct omap_hwmod omap3xxx_mmu_iva_hwmod; -static struct omap_hwmod_irq_info omap3xxx_mmu_iva_irqs[] = { - { .irq = 28 + OMAP_INTC_START, }, - { .irq = -1 } -}; static struct omap_hwmod_rst_info omap3xxx_mmu_iva_resets[] = { { .name = "mmu", .rst_shift = 1, .st_shift = 9 }, }; -static struct omap_hwmod_addr_space omap3xxx_mmu_iva_addrs[] = { - { - .pa_start = 0x5d00, - .pa_end = 0x5d7f, - .flags = ADDR_TYPE_RT, - }, - { } -}; - /* l3_main -> iva mmu */ static struct omap_hwmod_ocp_if omap3xxx_l3_main__mmu_iva = { .master = _l3_main_hwmod, .slave = _mmu_iva_hwmod, - .addr = omap3xxx_mmu_iva_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; static struct omap_hwmod omap3xxx_mmu_iva_hwmod = { .name = "mmu_iva", .class = _mmu_hwmod_class, - .mpu_irqs = omap3xxx_mmu_iva_irqs, .clkdm_name = "iva2_clkdm", .rst_lines = omap3xxx_mmu_iva_resets, .rst_lines_cnt = ARRAY_SIZE(omap3xxx_mmu_iva_resets), @@ -3062,7 +3021,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = { .idlest_idle_bit = OMAP3430_ST_IVA2_SHIFT, }, }, - .dev_attr = _iva_dev_attr, .flags = HWMOD_NO_IDLEST, }; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Cleanup legacy OMAP IOMMU device creation
Hi Tony, The following series removes the legacy platform device creation logic for OMAP IOMMU devices. I will cleanup the legacy support from the OMAP IOMMU driver in a subsequent merge window after this series makes it to mainline. Patches are based on 4.3-rc1 + the OMAP3 ISP instantiation cleanup patch [1]. All the patches need to be picked up sequentially, otherwise a NULL pointer dereference crash might be seen on OMAP3 legacy boots as the dev attribute structure is deferenced directly in mach-omap2/omap-iommu.c during platform data creation. Also, the last patch removes the structure definition altogether, so will cause build issues if picked separately from the hwmod cleanup patches. I do not have any boards where I can still perform a legacy-style boot, so patches verified using DT-boot only. regards Suman [1] https://patchwork.kernel.org/patch/6806891/ Suman Anna (4): ARM: OMAP2+: Remove legacy device instantiation of IOMMUs ARM: OMAP3: hwmod data: Remove legacy IOMMU data ARM: OMAP4: hwmod data: Remove legacy IOMMU attr and addrs ARM: OMAP2+: Remove omap_mmu_dev_attr structure arch/arm/mach-omap2/omap-iommu.c | 66 -- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 42 --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 31 -- include/linux/platform_data/iommu-omap.h | 9 4 files changed, 148 deletions(-) delete mode 100644 arch/arm/mach-omap2/omap-iommu.c -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
Hi Tony, On 09/03/2015 05:34 PM, Suman Anna wrote: > Hi Sakari, > > On 07/16/2015 07:58 AM, Tony Lindgren wrote: >> * Laurent Pinchart <laurent.pinch...@ideasonboard.com> [150716 05:57]: >>> The OMAP3 ISP is now fully supported in DT, remove its instantiation >>> from C code. >> >> Please feel to queue this along with the second patch in this series, >> this should not cause any merge conflicts: >> >> Acked-by: Tony Lindgren <t...@atomide.com> > > Just wondering if you have already queued this, I see the v4l changes in > linux-next, but not this patch. Also, can you confirm if this series is > making it into 4.3? > This patch is not in 4.3-rc1, can you pick this up for the next merge window? I am gonna send out some additional cleanup patches (removing legacy mailbox and iommu pieces) on top on this patch. The second patch in this series did make it. 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
[PATCH 1/2] ARM: OMAP2+: Remove legacy mailbox device instantiation
The legacy-style mailbox device creation is supported currently only for OMAP3, as all other SoCs are DT-boot only. Even on this SoC, there are no client drivers that utilize these mailbox devices. So, clean up the legacy-style mailbox device instantiation logic. The mailbox devices are already present and supported for the DT boot on OMAP3. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/devices.c | 28 1 file changed, 28 deletions(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index 9374da313e8e..f0f9901d90b0 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -18,7 +18,6 @@ #include #include #include -#include #include #include @@ -66,32 +65,6 @@ static int __init omap3_l3_init(void) } omap_postcore_initcall(omap3_l3_init); -#if defined(CONFIG_OMAP2PLUS_MBOX) || defined(CONFIG_OMAP2PLUS_MBOX_MODULE) -static inline void __init omap_init_mbox(void) -{ - struct omap_hwmod *oh; - struct platform_device *pdev; - struct omap_mbox_pdata *pdata; - - oh = omap_hwmod_lookup("mailbox"); - if (!oh) { - pr_err("%s: unable to find hwmod\n", __func__); - return; - } - if (!oh->dev_attr) { - pr_err("%s: hwmod doesn't have valid attrs\n", __func__); - return; - } - - pdata = (struct omap_mbox_pdata *)oh->dev_attr; - pdev = omap_device_build("omap-mailbox", -1, oh, pdata, sizeof(*pdata)); - WARN(IS_ERR(pdev), "%s: could not build device, err %ld\n", - __func__, PTR_ERR(pdev)); -} -#else -static inline void omap_init_mbox(void) { } -#endif /* CONFIG_OMAP2PLUS_MBOX */ - static inline void omap_init_sti(void) {} #if defined(CONFIG_SND_SOC) || defined(CONFIG_SND_SOC_MODULE) @@ -246,7 +219,6 @@ static int __init omap2_init_devices(void) omap_init_audio(); /* If dtb is there, the devices will be created dynamically */ if (!of_have_populated_dt()) { - omap_init_mbox(); omap_init_mcspi(); omap_init_sham(); omap_init_aes(); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Cleanup legacy OMAP mailbox support
Hi Tony, The following series removes the legacy platform device creation for OMAP mailbox devices. I will remove the platform data file alongside the non-DT support cleanup in the driver. Patches based on 4.3-rc1 + the patch on mach-omap2/devices.c that removes the OMAP3 ISP instantiation in legacy-mode [1]. The hwmod cleanup patch can be picked up independently if needed - it will just fail to create the legacy devices in omap_init_mbox(). These are only build tested and boot tested on OMAP3 in DT-mode, as I do not have any platforms where I can still perform a legacy-style boot. regards Suman [1] https://patchwork.kernel.org/patch/6806891/ Suman Anna (2): ARM: OMAP2+: Remove legacy mailbox device instantiation ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs arch/arm/mach-omap2/devices.c | 28 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 29 - 2 files changed, 57 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs
Remove the mailbox attribute data, irq info and hwmod addr space data that are used for creating the legacy-style mailbox devices, there is no need for these as the support for legacy-mode for this IP is being dropped. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 29 - 1 file changed, 29 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index dc55f8dedf2c..aff78d5198d2 100644 --- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c @@ -26,7 +26,6 @@ #include #include #include -#include #include #include "soc.h" @@ -1506,26 +1505,9 @@ static struct omap_hwmod_class omap3xxx_mailbox_hwmod_class = { .sysc = _mailbox_sysc, }; -static struct omap_mbox_dev_info omap3xxx_mailbox_info[] = { - { .name = "dsp", .tx_id = 0, .rx_id = 1 }, -}; - -static struct omap_mbox_pdata omap3xxx_mailbox_attrs = { - .num_users = 2, - .num_fifos = 2, - .info_cnt = ARRAY_SIZE(omap3xxx_mailbox_info), - .info = omap3xxx_mailbox_info, -}; - -static struct omap_hwmod_irq_info omap3xxx_mailbox_irqs[] = { - { .irq = 26 + OMAP_INTC_START, }, - { .irq = -1 }, -}; - static struct omap_hwmod omap3xxx_mailbox_hwmod = { .name = "mailbox", .class = _mailbox_hwmod_class, - .mpu_irqs = omap3xxx_mailbox_irqs, .main_clk = "mailboxes_ick", .prcm = { .omap2 = { @@ -1536,7 +1518,6 @@ static struct omap_hwmod omap3xxx_mailbox_hwmod = { .idlest_idle_bit = OMAP3430_ST_MAILBOXES_SHIFT, }, }, - .dev_attr = _mailbox_attrs, }; /* @@ -3276,20 +3257,10 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_per__mcbsp3_sidetone = { .user = OCP_USER_MPU, }; -static struct omap_hwmod_addr_space omap3xxx_mailbox_addrs[] = { - { - .pa_start = 0x48094000, - .pa_end = 0x480941ff, - .flags = ADDR_TYPE_RT, - }, - { } -}; - /* l4_core -> mailbox */ static struct omap_hwmod_ocp_if omap3xxx_l4_core__mailbox = { .master = _l4_core_hwmod, .slave = _mailbox_hwmod, - .addr = omap3xxx_mailbox_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP hwspinlock hwmod cleanup
Hi Paul, Following are couple of hwmod cleanup patches for HwSpinlock IP. Patches based on 4.3-rc1. The legacy platform device instantiation logic has been cleaned up in 4.2 kernel when DT-support was added to the OMAP HwSpinlock driver. regards Suman Suman Anna (2): ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs ARM: DRA7: hwmod data: Remove spinlock hwmod addrs arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 -- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 -- 2 files changed, 20 deletions(-) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: DRA7: hwmod data: Remove spinlock hwmod addrs
The legacy-style device creation logic for hwspinlock has been removed after the DT-support was added to the driver. The hwmod addr space for spinlock is therefore no longer needed, so remove it. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c index 562247bced49..60756ae75a65 100644 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c @@ -3029,21 +3029,11 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__smartreflex_mpu = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; -static struct omap_hwmod_addr_space dra7xx_spinlock_addrs[] = { - { - .pa_start = 0x4a0f6000, - .pa_end = 0x4a0f6fff, - .flags = ADDR_TYPE_RT - }, - { } -}; - /* l4_cfg -> spinlock */ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__spinlock = { .master = _l4_cfg_hwmod, .slave = _spinlock_hwmod, .clk= "l3_iclk_div", - .addr = dra7xx_spinlock_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs
The legacy-style device creation logic for hwspinlock has been removed after the DT-support was added to the driver. The hwmod addr space for spinlock is therefore no longer needed, so remove it. Signed-off-by: Suman Anna <s-a...@ti.com> --- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c index 43eebf2c59e2..a5e444b1e57a 100644 --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c @@ -4471,21 +4471,11 @@ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__smartreflex_mpu = { .user = OCP_USER_MPU | OCP_USER_SDMA, }; -static struct omap_hwmod_addr_space omap44xx_spinlock_addrs[] = { - { - .pa_start = 0x4a0f6000, - .pa_end = 0x4a0f6fff, - .flags = ADDR_TYPE_RT - }, - { } -}; - /* l4_cfg -> spinlock */ static struct omap_hwmod_ocp_if omap44xx_l4_cfg__spinlock = { .master = _l4_cfg_hwmod, .slave = _spinlock_hwmod, .clk= "l4_div_ck", - .addr = omap44xx_spinlock_addrs, .user = OCP_USER_MPU | OCP_USER_SDMA, }; -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation
Hi Sakari, On 07/16/2015 07:58 AM, Tony Lindgren wrote: > * Laurent Pinchart[150716 05:57]: >> The OMAP3 ISP is now fully supported in DT, remove its instantiation >> from C code. > > Please feel to queue this along with the second patch in this series, > this should not cause any merge conflicts: > > Acked-by: Tony Lindgren Just wondering if you have already queued this, I see the v4l changes in linux-next, but not this patch. Also, can you confirm if this series is making it into 4.3? 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: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx
Hi Tony, Sorry for the long delay in getting back on this. I will repost the series once 4.3-rc1 is out, but at the moment I do not think any changes are required. Let me know if you still need any additional details. >>>> On 07/23/2015 02:24 AM, Tony Lindgren wrote: >>>>> * Suman Anna <s-a...@ti.com> [150722 09:25]: >>>>>> On 07/22/2015 12:26 AM, Tony Lindgren wrote: >>>>>>> >>>>>>> I don't like using syscon for tinkering directly with SoC registers. >>>>>> >>>>>> This is not a SoC-level register, but a register within a sub-module of >>>>>> the DSP processor sub-system. The DSP_SYSTEM sub-module in general is >>>>>> described in Section 5.3.3 of the TRM [1], and it implements different >>>>>> functionalities like the PRCM handshaking, wakeup logic and DSP >>>>>> subsystem top-level configuration. It is a module present within the DSP >>>>>> processor sub-system, so can only be accessed when the sub-system is >>>>>> clocked and the appropriate reset is released. >>>>> >>>>> OK so if it's specific to the DSP driver along the lines of sysc and >>>>> syss registers. >>>> >>>> There will be those registers too within the MMU config register space, >>>> even for DRA7xx MMUs. This is different, think of it like a register in >>>> the Control module except that it is present within the DSP sub-system >>>> instead of at the SoC level. >>> >>> And what is taking care of pm_runtime_get here to ensure the module >>> is powered and clocked? >> >> pm_runtime_get_sync is indeed getting invoked, its just the current >> patch doesn't include the code block that invokes it. The function that >> invokes omap2_iommu_enable does so after a call to the >> pm_runtime_get_sync() call. > > OK > >>> I think you are missing a layer here and it's the Linux kernel side >>> device driver for DSP that initializes things. >> >> We already have separate drivers for MMUs (omap-iommu) and the processor >> management (omap-rproc). The former manages all the low-level >> programming sequences for the MMUs, while the latter manages the >> low-level reset etc, and is a client user of the respective IOMMU >> device. Both integrate into the respective frameworks. The IOMMU API >> invocations are handled in the remoteproc core, with the OMAP remoteproc >> driver publishing itself as having an MMU with the remoteproc core. The >> IOMMU API invoke the appropriate iommu_ops. >> >> You can lookup the functions rproc_enable_iommu()/rproc_disable_iommu() >> in the remoteproc core. The IOMMU enabling sequences happen within the >> iommu_attach_device() API. The call flow is >> iommu_attach_device()->omap_iommu_attach_dev()->omap_iommu_attach()-> >> iommu_enable()-> >>omap_device_deassert_hardreset, pm_runtime_get_sync, omap2_iommu_enable. > > OK. The thing to check here is that you have a separate device driver > for each sysc/syss device registers. This is because each hardware module > can be independently clocked and idled. Otherwise things will break at > some point. And no "things are configured for autoidle" or "we're not > doing PM is not a good excuse here" :) > > Can you please check that? If the remoteproc driver and iommu driver > are tinkering with registers in separate hardware modules, we have > a layering violation. My guess is that we have at least two hardware > modules involved here, one for the iommu and one for the DSP device. Only the IOMMU has a SYSC/SYSS device register. It has both a soft-reset as well as a hard-reset line. The IOMMU stays in reset, and its state machine/programming is controlled through the remoteproc driver. The clock source is also single clock going into the remote processor subsystem, and split up internally to feed the memories and the processors. For the PRCM to auto-gate the clocks, we also need the processor to be executing a IDLE (DSPs) or WFI/WFE (Cortex M3/M4s). Just the IOMMU will allow the OCP idle because of the associated sysc/syss registers. Depending on the remote processor, there might be a separate internal module (like the DSPs usually have a separate SYSC module), but that programming is left to the software running on the DSP. > >>>>> Typically we handle these registers by mapping them to the PM runtime >>>>> functions for the interconnect so we can reset and idle the hardware >>>>> modules even if there is no driver, see for example >>&
Re: [PATCH v2 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle
Hi Tony, On 08/05/2015 05:28 AM, Tony Lindgren wrote: * Dave Gerlach d-gerl...@ti.com [150717 13:59]: --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt @@ -75,6 +75,14 @@ data that represent the following: Cell #3 (usr_id) - mailbox user id for identifying the interrupt line associated with generating a tx/rx fifo interrupt. +Optional Properties: + +- ti,mbox-send-noirq: Quirk flag to allow the client user of this sub-mailbox +to send messages without triggering a Tx ready interrupt, +and to control the Tx ticker. Should be used only on +sub-mailboxes used to communicate with WkupM3 remote +processor on AM33xx/AM43xx SoCs. + Hmm can't you do this just by setting a flag in the device driver based on the compatible string? We can't because there can be other users like PRUSS which will use a sub-mailbox in a regular fashion. The compatible serves the IP and there can be multiple sub-mailboxes underneath it, and this quirk is needed only on the one that's used by the WkupM3. Jassi, Do you have any comments on this? 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: [PATCH 00/11] Some OMAP IOMMU cleanup patches
On 08/03/2015 08:55 AM, Joerg Roedel wrote: On Mon, Jul 20, 2015 at 05:33:22PM -0500, Suman Anna wrote: Suman Anna (11): Documentation: dt: Add #iommu-cells info to OMAP iommu bindings iommu/omap: Remove all module references iommu/omap: Move debugfs functions to omap-iommu-debug.c iommu/omap: Protect omap-iopgtable.h against double inclusion iommu/omap: Remove unused union fields iommu/omap: Remove trailing semi-colon from a macro iommu/omap: Remove unnecessary error traces on alloc failures iommu/omap: Use BIT(x) macros in omap-iopgtable.h iommu/omap: Use BIT(x) macros in omap-iommu.h iommu/omap: Align code with open parenthesis Applied these patches to arm/omap. Thanks Joerg. iommu/omap: Split multiple assignments into separate lines Did not apply this one, there is nothing wrong with multiple assignments. Yeah, that was just to satisfy checkpatch --strict. 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: [PATCH 0/2] DRA7 DSP MMU config support
On 08/03/2015 11:31 AM, Joerg Roedel wrote: On Tue, Jul 21, 2015 at 06:55:34PM -0500, Suman Anna wrote: The patches are baselined on 4.2-rc3 + the recent OMAP IOMMU cleanup series [1]. I will post the DTS patches separately to allow Tony to pick them up independently. From the discussion it looks like some more work is necessary here. Before you repost, please also test on older omap hardware to make sure nothing breaks there. Please also describe the testing you did in the repost. Yes, sure will do. I will repost once the next -rc1 is out. 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: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx
Hi Tony, On 07/23/2015 11:30 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150723 09:25]: Hi Tony, On 07/23/2015 02:24 AM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150722 09:25]: On 07/22/2015 12:26 AM, Tony Lindgren wrote: I don't like using syscon for tinkering directly with SoC registers. This is not a SoC-level register, but a register within a sub-module of the DSP processor sub-system. The DSP_SYSTEM sub-module in general is described in Section 5.3.3 of the TRM [1], and it implements different functionalities like the PRCM handshaking, wakeup logic and DSP subsystem top-level configuration. It is a module present within the DSP processor sub-system, so can only be accessed when the sub-system is clocked and the appropriate reset is released. OK so if it's specific to the DSP driver along the lines of sysc and syss registers. There will be those registers too within the MMU config register space, even for DRA7xx MMUs. This is different, think of it like a register in the Control module except that it is present within the DSP sub-system instead of at the SoC level. And what is taking care of pm_runtime_get here to ensure the module is powered and clocked? pm_runtime_get_sync is indeed getting invoked, its just the current patch doesn't include the code block that invokes it. The function that invokes omap2_iommu_enable does so after a call to the pm_runtime_get_sync() call. I think you are missing a layer here and it's the Linux kernel side device driver for DSP that initializes things. We already have separate drivers for MMUs (omap-iommu) and the processor management (omap-rproc). The former manages all the low-level programming sequences for the MMUs, while the latter manages the low-level reset etc, and is a client user of the respective IOMMU device. Both integrate into the respective frameworks. The IOMMU API invocations are handled in the remoteproc core, with the OMAP remoteproc driver publishing itself as having an MMU with the remoteproc core. The IOMMU API invoke the appropriate iommu_ops. You can lookup the functions rproc_enable_iommu()/rproc_disable_iommu() in the remoteproc core. The IOMMU enabling sequences happen within the iommu_attach_device() API. The call flow is iommu_attach_device()-omap_iommu_attach_dev()-omap_iommu_attach()- iommu_enable()- omap_device_deassert_hardreset, pm_runtime_get_sync, omap2_iommu_enable. Typically we handle these registers by mapping them to the PM runtime functions for the interconnect so we can reset and idle the hardware modules even if there is no driver, see for example omap54xx_mmu_dsp_hwmod. I haven't yet submitted the DRA7xx hwmods, but they will look almost exactly like the OMAP5 ones. The reset and idle on these are in general not effective at boot time since these are also controlled by a hard-reset line, so that's left to the drivers to deal with it through the omap_device_deassert_hardreset API. If the MMU configuration is one time init, it may make sense to add it to the hwmod reset function. However, if the Linux kernel side driver needs to configure things depending on the DSP firmware, it should be done in the kernel side device driver. The MMU configuration comes into picture whenever the remoteproc driver is being booted and shut down, and also during suspend (no support for this yet in mainline on OMAP rproc). Today, the hwmod _enable/_idle/reset functions alone are not enough to power on the OMAP remoteproc/iommus. We need sequencing calls to both omap_device_assert/_deassert_hardreset (done through pdata-quirks) and pm_runtime API to achieve this. We should use some Linux generic framework for configuring these bits to avoid nasty dependencies between various hardware modules on the SoC. What does DSP_SYS_MMU_CONFIG register do? It seems it's probably a regulator or a gate clock? If so, it should be set up as a regulator or a clock and then the omap-iommu driver can just use regulator or clcok framework to request the resource. No, its neither. It is a control bit that dictates whether the processor/EDMA addresses go through the respective MMU or not. The register currently has 4 bits (bit 0 in each nibble), one each for enabling each MMU and requesting an MMU abort on each. The MMU integration and enablement notes are detailed in Section 5.3.6 of the TRM [1], and the DSP_SYS_MMU_CONFIG register layout is in Table 5-28 (Page 1641). OK yeah seems like it should be handled by the DSP driver during probe after doing pm_runtime_get. Then the driver can configure things like IOMMU and load firmware. Or am I missing something here? The DSP (remoteproc) driver uses the generic IOMMU API, and all the IOMMU enabling sequence is transparent to the DSP driver. So, any configuration/enabling sequence specific to the IOMMU has to be handled within the respective IOMMU platform driver that gets integrated into the IOMMU API. To me
Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx
Hi Tony, On 07/23/2015 02:24 AM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150722 09:25]: On 07/22/2015 12:26 AM, Tony Lindgren wrote: I don't like using syscon for tinkering directly with SoC registers. This is not a SoC-level register, but a register within a sub-module of the DSP processor sub-system. The DSP_SYSTEM sub-module in general is described in Section 5.3.3 of the TRM [1], and it implements different functionalities like the PRCM handshaking, wakeup logic and DSP subsystem top-level configuration. It is a module present within the DSP processor sub-system, so can only be accessed when the sub-system is clocked and the appropriate reset is released. OK so if it's specific to the DSP driver along the lines of sysc and syss registers. There will be those registers too within the MMU config register space, even for DRA7xx MMUs. This is different, think of it like a register in the Control module except that it is present within the DSP sub-system instead of at the SoC level. Typically we handle these registers by mapping them to the PM runtime functions for the interconnect so we can reset and idle the hardware modules even if there is no driver, see for example omap54xx_mmu_dsp_hwmod. I haven't yet submitted the DRA7xx hwmods, but they will look almost exactly like the OMAP5 ones. The reset and idle on these are in general not effective at boot time since these are also controlled by a hard-reset line, so that's left to the drivers to deal with it through the omap_device_deassert_hardreset API. We should use some Linux generic framework for configuring these bits to avoid nasty dependencies between various hardware modules on the SoC. What does DSP_SYS_MMU_CONFIG register do? It seems it's probably a regulator or a gate clock? If so, it should be set up as a regulator or a clock and then the omap-iommu driver can just use regulator or clcok framework to request the resource. No, its neither. It is a control bit that dictates whether the processor/EDMA addresses go through the respective MMU or not. The register currently has 4 bits (bit 0 in each nibble), one each for enabling each MMU and requesting an MMU abort on each. The MMU integration and enablement notes are detailed in Section 5.3.6 of the TRM [1], and the DSP_SYS_MMU_CONFIG register layout is in Table 5-28 (Page 1641). OK yeah seems like it should be handled by the DSP driver during probe after doing pm_runtime_get. Then the driver can configure things like IOMMU and load firmware. Or am I missing something here? The DSP (remoteproc) driver uses the generic IOMMU API, and all the IOMMU enabling sequence is transparent to the DSP driver. So, any configuration/enabling sequence specific to the IOMMU has to be handled within the respective IOMMU platform driver that gets integrated into the IOMMU API. regards Suman [1] http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx
Hi Tony, On 07/22/2015 12:26 AM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150721 16:58]: --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -26,6 +26,8 @@ #include linux/of_iommu.h #include linux/of_irq.h #include linux/of_platform.h +#include linux/regmap.h +#include linux/mfd/syscon.h #include asm/cacheflush.h @@ -112,6 +114,18 @@ void omap_iommu_restore_ctx(struct device *dev) } EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx); +static void dra7_cfg_dspsys_mmu(struct omap_iommu *obj, bool enable) +{ +u32 val, mask; + +if (!obj-syscfg) +return; + +mask = (1 (obj-id * DSP_SYS_MMU_CONFIG_EN_SHIFT)); +val = enable ? mask : 0; +regmap_update_bits(obj-syscfg, DSP_SYS_MMU_CONFIG, mask, val); +} + static void __iommu_set_twl(struct omap_iommu *obj, bool on) I don't like using syscon for tinkering directly with SoC registers. This is not a SoC-level register, but a register within a sub-module of the DSP processor sub-system. The DSP_SYSTEM sub-module in general is described in Section 5.3.3 of the TRM [1], and it implements different functionalities like the PRCM handshaking, wakeup logic and DSP subsystem top-level configuration. It is a module present within the DSP processor sub-system, so can only be accessed when the sub-system is clocked and the appropriate reset is released. We should use some Linux generic framework for configuring these bits to avoid nasty dependencies between various hardware modules on the SoC. What does DSP_SYS_MMU_CONFIG register do? It seems it's probably a regulator or a gate clock? If so, it should be set up as a regulator or a clock and then the omap-iommu driver can just use regulator or clcok framework to request the resource. No, its neither. It is a control bit that dictates whether the processor/EDMA addresses go through the respective MMU or not. The register currently has 4 bits (bit 0 in each nibble), one each for enabling each MMU and requesting an MMU abort on each. The MMU integration and enablement notes are detailed in Section 5.3.6 of the TRM [1], and the DSP_SYS_MMU_CONFIG register layout is in Table 5-28 (Page 1641). regards Suman [1] http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf -- 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 02/11] iommu/omap: Remove all module references
Hi Laurent, On Monday 20 July 2015 17:33:24 Suman Anna wrote: The OMAP IOMMU driver has been adapted to the IOMMU framework for a while now, and it does not support being built as a module anymore. So, remove all the module references from the OMAP IOMMU driver. While at it, also relocate a comment around the subsys_initcall to avoid a checkpatch strict warning about using a blank line after function/struct/union/enum declarations. Signed-off-by: Suman Anna s-a...@ti.com I think this is one of the checkpatch warnings that can be safely ignored, but it doesn't matter much. The comment will be removed after the OMAP3 ISP and OMAP IOMMU drivers get support for a saner IOMMU probing dependency order solution. The code seems fine to me. Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Yes, indeed. I have also started to work on some patches to switch to using the IOMMU_OF_DECLARE init, that should also help us. I will post those for the 4.4 kernel merge window. 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
[PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx
The DSP MMUs on DRA7xx SoC requires configuring an additional MMU_CONFIG register present in the DSP_SYSTEM sub module. This setting dictates whether the DSP Core's MDMA and EDMA traffic is routed through the respective MMU or not. Add the support to the OMAP iommu driver so that the traffic is not bypassed when enabling the MMUs. The MMU_CONFIG register has two different bits for enabling each of these two MMUs present in the DSP processor sub-system on DRA7xx. An id field is added to the OMAP iommu object to identify and enable each IOMMU. The id information and the DSP_SYSTEM.MMU_CONFIG register programming is achieved through the processing of the optional ti,syscon-mmuconfig property. A proper value is assigned to the id field only when this property is present. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu.c | 58 ++ drivers/iommu/omap-iommu.h | 9 +++ 2 files changed, 67 insertions(+) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index fe742c01a4f2..0849a5927732 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -26,6 +26,8 @@ #include linux/of_iommu.h #include linux/of_irq.h #include linux/of_platform.h +#include linux/regmap.h +#include linux/mfd/syscon.h #include asm/cacheflush.h @@ -112,6 +114,18 @@ void omap_iommu_restore_ctx(struct device *dev) } EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx); +static void dra7_cfg_dspsys_mmu(struct omap_iommu *obj, bool enable) +{ + u32 val, mask; + + if (!obj-syscfg) + return; + + mask = (1 (obj-id * DSP_SYS_MMU_CONFIG_EN_SHIFT)); + val = enable ? mask : 0; + regmap_update_bits(obj-syscfg, DSP_SYS_MMU_CONFIG, mask, val); +} + static void __iommu_set_twl(struct omap_iommu *obj, bool on) { u32 l = iommu_read_reg(obj, MMU_CNTL); @@ -147,6 +161,8 @@ static int omap2_iommu_enable(struct omap_iommu *obj) iommu_write_reg(obj, pa, MMU_TTB); + dra7_cfg_dspsys_mmu(obj, true); + if (obj-has_bus_err_back) iommu_write_reg(obj, MMU_GP_REG_BUS_ERR_BACK_EN, MMU_GP_REG); @@ -161,6 +177,7 @@ static void omap2_iommu_disable(struct omap_iommu *obj) l = ~MMU_CNTL_MASK; iommu_write_reg(obj, l, MMU_CNTL); + dra7_cfg_dspsys_mmu(obj, false); dev_dbg(obj-dev, %s is shutting down\n, obj-name); } @@ -864,6 +881,42 @@ static void omap_iommu_detach(struct omap_iommu *obj) dev_dbg(obj-dev, %s: %s\n, __func__, obj-name); } +static int omap_iommu_dra7_get_dsp_system_cfg(struct platform_device *pdev, + struct omap_iommu *obj) +{ + struct device_node *np = pdev-dev.of_node; + int ret; + + if (!of_device_is_compatible(np, ti,dra7-dsp-iommu)) + return 0; + + if (!of_property_read_bool(np, ti,syscon-mmuconfig)) { + dev_err(pdev-dev, ti,syscon-mmuconfig property is missing\n); + return -EINVAL; + } + + obj-syscfg = + syscon_regmap_lookup_by_phandle(np, ti,syscon-mmuconfig); + if (IS_ERR(obj-syscfg)) { + /* can fail with -EPROBE_DEFER */ + ret = PTR_ERR(obj-syscfg); + return ret; + } + + if (of_property_read_u32_index(np, ti,syscon-mmuconfig, 1, + obj-id)) { + dev_err(pdev-dev, couldn't get the IOMMU instance id within subsystem\n); + return -EINVAL; + } + + if (obj-id != 0 obj-id != 1) { + dev_err(pdev-dev, invalid IOMMU instance id\n); + return -EINVAL; + } + + return 0; +} + /* * OMAP Device MMU(IOMMU) detection */ @@ -907,6 +960,10 @@ static int omap_iommu_probe(struct platform_device *pdev) if (IS_ERR(obj-regbase)) return PTR_ERR(obj-regbase); + err = omap_iommu_dra7_get_dsp_system_cfg(pdev, obj); + if (err) + return err; + irq = platform_get_irq(pdev, 0); if (irq 0) return -ENODEV; @@ -943,6 +1000,7 @@ static const struct of_device_id omap_iommu_of_match[] = { { .compatible = ti,omap2-iommu }, { .compatible = ti,omap4-iommu }, { .compatible = ti,dra7-iommu }, + { .compatible = ti,dra7-dsp-iommu }, {}, }; diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h index a656df2f9e03..59628e5017b4 100644 --- a/drivers/iommu/omap-iommu.h +++ b/drivers/iommu/omap-iommu.h @@ -30,6 +30,7 @@ struct iotlb_entry { struct omap_iommu { const char *name; void __iomem*regbase; + struct regmap *syscfg; struct device *dev; struct iommu_domain *domain; struct dentry *debug_dir; @@ -48,6 +49,7 @@ struct omap_iommu { void *ctx; /* iommu context: registres saved area */ int has_bus_err_back; + u32 id
[PATCH 0/2] DRA7 DSP MMU config support
Hi, This series adds the basic support in the OMAP IOMMU driver to enable/disable DSP IOMMUs for the DRA7xx family of SoCs. The DRA7 family has two MMUs within the DSP processor subsystems. This is the first time this was designed so in the silicon compared to the equivalent ones on OMAP2+ SoCs. Each MMU requires a specific bit to be turned on within a register from a separate sub-module DSP_SYSTEM present within the respective processor subsystem. The DSP_SYSTEM sub-module is represented as a syscon node, and an additional property ti,syscon-mmuconfig is used alongside a unique compatible property for configuring these devices. The register and bit offset is coded up in the driver while the DT property references the syscon phandle the MMU instance number. The binding support could have been done in couple of other ways, like using separate compatible each for the DSP processor MMU the DSP EDMA MMU that automatically identifies the instance number; and/or coding up the register offset bit position/offset in the syscon property, so let me know if the current approach is fine. The patches are baselined on 4.2-rc3 + the recent OMAP IOMMU cleanup series [1]. I will post the DTS patches separately to allow Tony to pick them up independently. regards Suman [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-July/013659.html Suman Anna (2): Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs iommu/omap: Add support for configuring dsp iommus on DRA7xx .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++ drivers/iommu/omap-iommu.c | 58 ++ drivers/iommu/omap-iommu.h | 9 3 files changed, 94 insertions(+) -- 2.4.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 1/2] Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs
The DSP processor sub-systems on DRA7xx have two MMU instances each, one for the processor core and the other for an internal EDMA block. These MMUs need an additional shared register to be programmed in the DSP_SYSTEM sub-module to be enabled properly. The OMAP IOMMU bindings is updated to account for this additional syscon property required for these DSP IOMMU instances on DRA7xx SoCs. A new compatible ti,dra7-dsp-iommu is also defined to distinguish these devices specifically from other DRA7 IOMMU devices. An example of the DRA7 DSP IOMMU nodes is also added to the document for clarity. Signed-off-by: Suman Anna s-a...@ti.com --- .../devicetree/bindings/iommu/ti,omap-iommu.txt| 27 ++ 1 file changed, 27 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt index 869699925fd5..4bd10dd881b8 100644 --- a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -4,6 +4,7 @@ Required properties: - compatible : Should be one of, ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances + ti,dra7-dsp-iommu for DRA7xx DSP IOMMU instances ti,dra7-iommu for DRA7xx IOMMU instances - ti,hwmods : Name of the hwmod associated with the IOMMU instance - reg: Address space for the configuration registers @@ -19,6 +20,13 @@ Optional properties: Should be either 8 or 32 (default: 32) - ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing back a bus error response on MMU faults. +- ti,syscon-mmuconfig : Should be a pair of the phandle to the DSP_SYSTEM +syscon node that contains the additional control +register for enabling the MMU, and the MMU instance +number (0-indexed) within the sub-system. This property +is required for DSP IOMMU instances on DRA7xx SoCs. The +instance number should be 0 for DSP MDMA MMUs and 1 for +DSP EDMA MMUs. Example: /* OMAP3 ISP MMU */ @@ -30,3 +38,22 @@ Example: ti,hwmods = mmu_isp; ti,#tlb-entries = 8; }; + + /* DRA74x DSP2 MMUs */ + mmu0_dsp2: mmu@41501000 { + compatible = ti,dra7-dsp-iommu; + reg = 0x41501000 0x100; + interrupts = GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH; + ti,hwmods = mmu0_dsp2; + #iommu-cells = 0; + ti,syscon-mmuconfig = dsp2_system 0x0; + }; + + mmu1_dsp2: mmu@41502000 { + compatible = ti,dra7-dsp-iommu; + reg = 0x41502000 0x100; + interrupts = GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH; + ti,hwmods = mmu1_dsp2; + #iommu-cells = 0; + ti,syscon-mmuconfig = dsp2_system 0x1; + }; -- 2.4.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 3/4] ARM: dts: DRA7: Add common IOMMU nodes
The DRA7xx family of SOCs have two IPUs and one DSP processor subsystems in common. The IOMMU DT nodes have been added for these processor subsystems, and have been disabled by default. These MMUs are very similar to those on OMAP4 and OMAP5, with the only difference being the presence of a second MMU within the DSP subsystem for the EDMA port. The DSP IOMMUs also need an additional 'ti,syscon-mmuconfig' property compared to the IPU IOMMUs. NOTE: The enabling of these nodes is left to the respective board dts files. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/boot/dts/dra7.dtsi | 40 1 file changed, 40 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 1c96729641b6..0754df4ca59c 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -911,6 +911,46 @@ status = disabled; }; + mmu0_dsp1: mmu@40d01000 { + compatible = ti,dra7-dsp-iommu; + reg = 0x40d01000 0x100; + interrupts = GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH; + ti,hwmods = mmu0_dsp1; + #iommu-cells = 0; + ti,syscon-mmuconfig = dsp1_system 0x0; + status = disabled; + }; + + mmu1_dsp1: mmu@40d02000 { + compatible = ti,dra7-dsp-iommu; + reg = 0x40d02000 0x100; + interrupts = GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH; + ti,hwmods = mmu1_dsp1; + #iommu-cells = 0; + ti,syscon-mmuconfig = dsp1_system 0x1; + status = disabled; + }; + + mmu_ipu1: mmu@58882000 { + compatible = ti,dra7-iommu; + reg = 0x58882000 0x100; + interrupts = GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH; + ti,hwmods = mmu_ipu1; + #iommu-cells = 0; + ti,iommu-bus-err-back; + status = disabled; + }; + + mmu_ipu2: mmu@55082000 { + compatible = ti,dra7-iommu; + reg = 0x55082000 0x100; + interrupts = GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH; + ti,hwmods = mmu_ipu2; + #iommu-cells = 0; + ti,iommu-bus-err-back; + status = disabled; + }; + abb_mpu: regulator-abb-mpu { compatible = ti,abb-v3; regulator-name = abb_mpu; -- 2.4.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 1/4] ARM: dts: DRA7: Add dsp1_system syscon node
The DSP_SYSTEM sub-module is a dedicated system control logic module present within a DRA7 DSP processor sub-system. This module is responsible for power management, clock generation and connection to the device PRCM module. Add a syscon node for this module for the DSP1 processor sub-system. This is added as a syscon node as it is a common configuration module that can be used by the different IOMMU instances and the corresponding remoteproc device. The node is added to the common dra7.dtsi file, as the DSP1 processor sub-system is mostly common across all the variants of the DRA7 SoC family. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/boot/dts/dra7.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index 8f1e25bcecbd..1c96729641b6 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -296,6 +296,11 @@ reg = 0x4a002e00 0x7c; }; + dsp1_system: dsp_system@40d0 { + compatible = syscon; + reg = 0x40d0 0x100; + }; + sdma: dma-controller@4a056000 { compatible = ti,omap4430-sdma; reg = 0x4a056000 0x1000; -- 2.4.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 4/4] ARM: dts: DRA74x: Add IOMMU nodes for DSP2
The DRA74x family of SoCs have a second DSP, that also has two MMUs just like the DSP1 subsystem. Add the IOMMU nodes for this DSP2 subsystem in disabled state to the DRA74x specific DTS file, the nodes would need to be enabled appropriately in the respective board DTS files. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/boot/dts/dra74x.dtsi | 20 1 file changed, 20 insertions(+) diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi index 6cb112450ddd..612cc7e13bab 100644 --- a/arch/arm/boot/dts/dra74x.dtsi +++ b/arch/arm/boot/dts/dra74x.dtsi @@ -76,6 +76,26 @@ dr_mode = otg; }; }; + + mmu0_dsp2: mmu@41501000 { + compatible = ti,dra7-dsp-iommu; + reg = 0x41501000 0x100; + interrupts = GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH; + ti,hwmods = mmu0_dsp2; + #iommu-cells = 0; + ti,syscon-mmuconfig = dsp2_system 0x0; + status = disabled; + }; + + mmu1_dsp2: mmu@41502000 { + compatible = ti,dra7-dsp-iommu; + reg = 0x41502000 0x100; + interrupts = GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH; + ti,hwmods = mmu1_dsp2; + #iommu-cells = 0; + ti,syscon-mmuconfig = dsp2_system 0x1; + status = disabled; + }; }; }; -- 2.4.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 2/4] ARM: dts: DRA74x: Add dsp2_system syscon node
The DSP_SYSTEM sub-module is a dedicated system control logic module present within a DRA7 DSP processor sub-system. This module is responsible for power management, clock generation and connection to the device PRCM module. Add a syscon node for this module for the DSP2 processor sub-system. This is added as a syscon node as it is a common configuration module that can be used by the different IOMMU instances and the corresponding remoteproc device. The node is added to the dra74x.dtsi file, as the DSP2 processor subsystem is usually present only on the DRA74x variants of the DRA7 SoC family. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/boot/dts/dra74x.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/dra74x.dtsi b/arch/arm/boot/dts/dra74x.dtsi index fa995d0ca1f2..6cb112450ddd 100644 --- a/arch/arm/boot/dts/dra74x.dtsi +++ b/arch/arm/boot/dts/dra74x.dtsi @@ -52,6 +52,11 @@ }; ocp { + dsp2_system: dsp_system@4150 { + compatible = syscon; + reg = 0x4150 0x100; + }; + omap_dwc3_4: omap_dwc3_4@4894 { compatible = ti,dwc3; ti,hwmods = usb_otg_ss4; -- 2.4.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 0/4] Add DRA7 IOMMU DT nodes
Hi Tony, The following patches add the basic DT nodes for the DSP and IPU IOMMU devices for the DRA7xx SoC family. The first two patches add syscon nodes for DSP_SYSTEM sub-modules, while the last two add the IOMMU nodes. The IPU IOMMU nodes mostly are similar to existing ones on OMAP4 and OMAP5. The DSP sub-system though has two MMUs, with a dedicated MMU for the internal EDMA engine. On previous SoCs, a single MMU served both the DSP processor and the internal EDMA. The DSP IOMMU nodes require a new property to reference the syscon nodes, as they each need a specific bit to be set in a register within the corresponding DSP_SYSTEM sub-module. So, these are pending based on the equivalent bindings update series [1]. Please let me know if the binding looks ok to you, as this seems it can be done in couple of ways. Patches are based on 4.2-rc3. regards Suman [1] http://marc.info/?l=linux-omapm=143752295508435w=2 Suman Anna (4): ARM: dts: DRA7: Add dsp1_system syscon node ARM: dts: DRA74x: Add dsp2_system syscon node ARM: dts: DRA7: Add common IOMMU nodes ARM: dts: DRA74x: Add IOMMU nodes for DSP2 arch/arm/boot/dts/dra7.dtsi | 45 +++ arch/arm/boot/dts/dra74x.dtsi | 25 2 files changed, 70 insertions(+) -- 2.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Remove module references from IOMMU machine layer
Hi Tony, On 07/16/2015 02:16 AM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150710 13:45]: The OMAP IOMMU driver has been adapted to the IOMMU framework for a while now, and it no longer supports being built as a module. Cleanup all the module related references both from the code and in the build. While at it, also relocate a comment around the initcall to avoid a checkpatch strict warning about using a blank line after function/struct/union/enum declarations. OK applying into omap-for-v4.3/soc. Thanks. You may want to check few things after this: - Does it still need to be omap_subsys_initcall or can it happen later? Anything we can initialize later on is worth doing as then we have proper debug console available. This code will be cleaned up once the non-DT references/users for OMAP3 IOMMUs go away. I will do this in the next merge window once Laurent's OMAP3ISP legacy device creation cleanup series gets into mainline [1]. - For multi_v7_defconfig it would be nice to be able to make the driver/iommu components into standard Linux loadable modules. We used to be module before, and the built-in is coming from the IOMMU framework. The init function in the OMAP IOMMU driver already handles the multi_v7_defconfig scenario, so no issues there. - Actually you can probably get rid of mach-omap2/omap-iommu.c completely by implementing PM runtime and and possibly reset controller. Yeah, any need for this file after the non-DT device creation removal would arises from the PRCM/reset dependencies against API present in mach-omap2 layer only. regards Suman [1] http://marc.info/?l=linux-omapm=143705130631733w=2 -- 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/11] iommu/omap: Remove trailing semi-colon from a macro
Remove the trailing semi-colon in the DEBUG_FOPS_RO macro definition. This fixes the checking warning, WARNING: macros should not use a trailing semicolon Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu-debug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c index b4b96db37e6a..e9f116f18531 100644 --- a/drivers/iommu/omap-iommu-debug.c +++ b/drivers/iommu/omap-iommu-debug.c @@ -265,7 +265,7 @@ static int debug_read_pagetable(struct seq_file *s, void *data) .open = simple_open,\ .read = debug_read_##name, \ .llseek = generic_file_llseek, \ - }; + } DEBUG_FOPS_RO(regs); DEBUG_FOPS_RO(tlb); -- 2.4.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/11] iommu/omap: Move debugfs functions to omap-iommu-debug.c
The main OMAP IOMMU driver file has some helper functions used by the OMAP IOMMU debugfs functionality, and there is already a dedicated source file omap-iommu-debug.c dealing with these debugfs routines. Move all these functions to the omap-iommu-debug.c file, so that all the debugfs related routines are in one place. The move required exposing some new functions and moving some definitions to the internal omap-iommu.h header file. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu-debug.c | 111 + drivers/iommu/omap-iommu.c | 148 +-- drivers/iommu/omap-iommu.h | 28 ++-- 3 files changed, 137 insertions(+), 150 deletions(-) diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c index f3d20a2039d2..b4b96db37e6a 100644 --- a/drivers/iommu/omap-iommu-debug.c +++ b/drivers/iommu/omap-iommu-debug.c @@ -14,6 +14,7 @@ #include linux/io.h #include linux/slab.h #include linux/uaccess.h +#include linux/pm_runtime.h #include linux/debugfs.h #include linux/platform_data/iommu-omap.h @@ -29,6 +30,59 @@ static inline bool is_omap_iommu_detached(struct omap_iommu *obj) return !obj-domain; } +#define pr_reg(name) \ + do {\ + ssize_t bytes; \ + const char *str = %20s: %08x\n; \ + const int maxcol = 32; \ + bytes = snprintf(p, maxcol, str, __stringify(name), \ +iommu_read_reg(obj, MMU_##name)); \ + p += bytes; \ + len -= bytes; \ + if (len maxcol) \ + goto out; \ + } while (0) + +static ssize_t +omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len) +{ + char *p = buf; + + pr_reg(REVISION); + pr_reg(IRQSTATUS); + pr_reg(IRQENABLE); + pr_reg(WALKING_ST); + pr_reg(CNTL); + pr_reg(FAULT_AD); + pr_reg(TTB); + pr_reg(LOCK); + pr_reg(LD_TLB); + pr_reg(CAM); + pr_reg(RAM); + pr_reg(GFLUSH); + pr_reg(FLUSH_ENTRY); + pr_reg(READ_CAM); + pr_reg(READ_RAM); + pr_reg(EMU_FAULT_AD); +out: + return p - buf; +} + +static ssize_t omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, + ssize_t bytes) +{ + if (!obj || !buf) + return -EINVAL; + + pm_runtime_get_sync(obj-dev); + + bytes = omap2_iommu_dump_ctx(obj, buf, bytes); + + pm_runtime_put_sync(obj-dev); + + return bytes; +} + static ssize_t debug_read_regs(struct file *file, char __user *userbuf, size_t count, loff_t *ppos) { @@ -55,6 +109,63 @@ static ssize_t debug_read_regs(struct file *file, char __user *userbuf, return bytes; } +static int +__dump_tlb_entries(struct omap_iommu *obj, struct cr_regs *crs, int num) +{ + int i; + struct iotlb_lock saved; + struct cr_regs tmp; + struct cr_regs *p = crs; + + pm_runtime_get_sync(obj-dev); + iotlb_lock_get(obj, saved); + + for_each_iotlb_cr(obj, num, i, tmp) { + if (!iotlb_cr_valid(tmp)) + continue; + *p++ = tmp; + } + + iotlb_lock_set(obj, saved); + pm_runtime_put_sync(obj-dev); + + return p - crs; +} + +static ssize_t iotlb_dump_cr(struct omap_iommu *obj, struct cr_regs *cr, +char *buf) +{ + char *p = buf; + + /* FIXME: Need more detail analysis of cam/ram */ + p += sprintf(p, %08x %08x %01x\n, cr-cam, cr-ram, + (cr-cam MMU_CAM_P) ? 1 : 0); + + return p - buf; +} + +static size_t omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, + ssize_t bytes) +{ + int i, num; + struct cr_regs *cr; + char *p = buf; + + num = bytes / sizeof(*cr); + num = min(obj-nr_tlb_entries, num); + + cr = kcalloc(num, sizeof(*cr), GFP_KERNEL); + if (!cr) + return 0; + + num = __dump_tlb_entries(obj, cr, num); + for (i = 0; i num; i++) + p += iotlb_dump_cr(obj, cr + i, p); + kfree(cr); + + return p - buf; +} + static ssize_t debug_read_tlb(struct file *file, char __user *userbuf, size_t count, loff_t *ppos) { diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index eeecfc4073af..0fc00f31c39d 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c
[PATCH 04/11] iommu/omap: Protect omap-iopgtable.h against double inclusion
Protect the omap-pgtable.h header against double inclusion in source code by using the standard include guard mechanism. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iopgtable.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/iommu/omap-iopgtable.h b/drivers/iommu/omap-iopgtable.h index f891683e3f05..bfde5405f514 100644 --- a/drivers/iommu/omap-iopgtable.h +++ b/drivers/iommu/omap-iopgtable.h @@ -10,6 +10,9 @@ * published by the Free Software Foundation. */ +#ifndef _OMAP_IOPGTABLE_H +#define _OMAP_IOPGTABLE_H + /* * L2 table address mask and size definitions. */ @@ -93,3 +96,5 @@ static inline phys_addr_t omap_iommu_translate(u32 d, u32 va, u32 mask) /* to find an entry in the second-level page table. */ #define iopte_index(da)(((da) IOPTE_SHIFT) (PTRS_PER_IOPTE - 1)) #define iopte_offset(iopgd, da)(iopgd_page_vaddr(iopgd) + iopte_index(da)) + +#endif /* _OMAP_IOPGTABLE_H */ -- 2.4.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/11] iommu/omap: Remove all module references
The OMAP IOMMU driver has been adapted to the IOMMU framework for a while now, and it does not support being built as a module anymore. So, remove all the module references from the OMAP IOMMU driver. While at it, also relocate a comment around the subsys_initcall to avoid a checkpatch strict warning about using a blank line after function/struct/union/enum declarations. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu.c | 19 +-- 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index a22c33d6a486..eeecfc4073af 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -12,7 +12,6 @@ */ #include linux/err.h -#include linux/module.h #include linux/slab.h #include linux/interrupt.h #include linux/ioport.h @@ -1089,7 +1088,6 @@ static const struct of_device_id omap_iommu_of_match[] = { { .compatible = ti,dra7-iommu }, {}, }; -MODULE_DEVICE_TABLE(of, omap_iommu_of_match); static struct platform_driver omap_iommu_driver = { .probe = omap_iommu_probe, @@ -1405,20 +1403,5 @@ static int __init omap_iommu_init(void) return platform_driver_register(omap_iommu_driver); } -/* must be ready before omap3isp is probed */ subsys_initcall(omap_iommu_init); - -static void __exit omap_iommu_exit(void) -{ - kmem_cache_destroy(iopte_cachep); - - platform_driver_unregister(omap_iommu_driver); - - omap_iommu_debugfs_exit(); -} -module_exit(omap_iommu_exit); - -MODULE_DESCRIPTION(omap iommu: tlb and pagetable primitives); -MODULE_ALIAS(platform:omap-iommu); -MODULE_AUTHOR(Hiroshi DOYU, Paul Mundt and Toshihiro Kobayashi); -MODULE_LICENSE(GPL v2); +/* must be ready before omap3isp is probed */ -- 2.4.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 10/11] iommu/omap: Align code with open parenthesis
Fix all the occurrences of the following check warning generated with the checkpatch --strict option: CHECK: Alignment should match open parenthesis Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 4328d9855edb..36d0033c2ccb 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -787,14 +787,14 @@ static irqreturn_t iommu_fault_handler(int irq, void *data) if (!iopgd_is_table(*iopgd)) { dev_err(obj-dev, %s: errs:0x%08x da:0x%08x pgd:0x%p *pgd:px%08x\n, - obj-name, errs, da, iopgd, *iopgd); + obj-name, errs, da, iopgd, *iopgd); return IRQ_NONE; } iopte = iopte_offset(iopgd, da); dev_err(obj-dev, %s: errs:0x%08x da:0x%08x pgd:0x%p *pgd:0x%08x pte:0x%p *pte:0x%08x\n, - obj-name, errs, da, iopgd, *iopgd, iopte, *iopte); + obj-name, errs, da, iopgd, *iopgd, iopte, *iopte); return IRQ_NONE; } @@ -820,9 +820,8 @@ static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd) struct device *dev; struct omap_iommu *obj; - dev = driver_find_device(omap_iommu_driver.driver, NULL, - (void *)name, - device_match_by_alias); + dev = driver_find_device(omap_iommu_driver.driver, NULL, (void *)name, +device_match_by_alias); if (!dev) return ERR_PTR(-ENODEV); @@ -977,7 +976,7 @@ static u32 iotlb_init_entry(struct iotlb_entry *e, u32 da, u32 pa, int pgsz) } static int omap_iommu_map(struct iommu_domain *domain, unsigned long da, -phys_addr_t pa, size_t bytes, int prot) + phys_addr_t pa, size_t bytes, int prot) { struct omap_iommu_domain *omap_domain = to_omap_domain(domain); struct omap_iommu *oiommu = omap_domain-iommu_dev; @@ -1004,7 +1003,7 @@ static int omap_iommu_map(struct iommu_domain *domain, unsigned long da, } static size_t omap_iommu_unmap(struct iommu_domain *domain, unsigned long da, - size_t size) + size_t size) { struct omap_iommu_domain *omap_domain = to_omap_domain(domain); struct omap_iommu *oiommu = omap_domain-iommu_dev; @@ -1055,7 +1054,7 @@ out: } static void _omap_iommu_detach_dev(struct omap_iommu_domain *omap_domain, - struct device *dev) + struct device *dev) { struct omap_iommu *oiommu = dev_to_omap_iommu(dev); struct omap_iommu_arch_data *arch_data = dev-archdata.iommu; @@ -1076,7 +1075,7 @@ static void _omap_iommu_detach_dev(struct omap_iommu_domain *omap_domain, } static void omap_iommu_detach_dev(struct iommu_domain *domain, -struct device *dev) + struct device *dev) { struct omap_iommu_domain *omap_domain = to_omap_domain(domain); @@ -1137,7 +1136,7 @@ static void omap_iommu_domain_free(struct iommu_domain *domain) } static phys_addr_t omap_iommu_iova_to_phys(struct iommu_domain *domain, - dma_addr_t da) + dma_addr_t da) { struct omap_iommu_domain *omap_domain = to_omap_domain(domain); struct omap_iommu *oiommu = omap_domain-iommu_dev; @@ -1154,7 +1153,7 @@ static phys_addr_t omap_iommu_iova_to_phys(struct iommu_domain *domain, ret = omap_iommu_translate(*pte, da, IOLARGE_MASK); else dev_err(dev, bogus pte 0x%x, da 0x%llx, *pte, - (unsigned long long)da); + (unsigned long long)da); } else { if (iopgd_is_section(*pgd)) ret = omap_iommu_translate(*pgd, da, IOSECTION_MASK); @@ -1162,7 +1161,7 @@ static phys_addr_t omap_iommu_iova_to_phys(struct iommu_domain *domain, ret = omap_iommu_translate(*pgd, da, IOSUPER_MASK); else dev_err(dev, bogus pgd 0x%x, da 0x%llx, *pgd, - (unsigned long long)da); + (unsigned long long)da); } return ret; -- 2.4.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/11] iommu/omap: Remove unused union fields
There are couple of unions defined in the structures iotlb_entry and cr_regs. There are no usage/references to some of these union fields in the code, so clean them up and simplify the structures. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu.h | 23 +++ 1 file changed, 3 insertions(+), 20 deletions(-) diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h index b6cc90b2ba41..5b98408c18bf 100644 --- a/drivers/iommu/omap-iommu.h +++ b/drivers/iommu/omap-iommu.h @@ -22,12 +22,7 @@ struct iotlb_entry { u32 da; u32 pa; u32 pgsz, prsvd, valid; - union { - u16 ap; - struct { - u32 endian, elsz, mixed; - }; - }; + u32 endian, elsz, mixed; }; struct omap_iommu { @@ -54,20 +49,8 @@ struct omap_iommu { }; struct cr_regs { - union { - struct { - u16 cam_l; - u16 cam_h; - }; - u32 cam; - }; - union { - struct { - u16 ram_l; - u16 ram_h; - }; - u32 ram; - }; + u32 cam; + u32 ram; }; struct iotlb_lock { -- 2.4.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/11] iommu/omap: Use BIT(x) macros in omap-iopgtable.h
Switch to using the BIT(x) macros in omap-iopgtable.h where possible. This eliminates the following checkpatch check warning: CHECK: Prefer using the BIT macro A couple of macros that used zero bit shifting are defined directly to avoid the above warning on one of the macros. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iopgtable.h | 22 -- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/omap-iopgtable.h b/drivers/iommu/omap-iopgtable.h index bfde5405f514..01a315227bf0 100644 --- a/drivers/iommu/omap-iopgtable.h +++ b/drivers/iommu/omap-iopgtable.h @@ -13,25 +13,27 @@ #ifndef _OMAP_IOPGTABLE_H #define _OMAP_IOPGTABLE_H +#include linux/bitops.h + /* * L2 table address mask and size definitions. */ #define IOPGD_SHIFT20 -#define IOPGD_SIZE (1UL IOPGD_SHIFT) +#define IOPGD_SIZE BIT(IOPGD_SHIFT) #define IOPGD_MASK (~(IOPGD_SIZE - 1)) /* * section address mask and size definitions. */ #define IOSECTION_SHIFT20 -#define IOSECTION_SIZE (1UL IOSECTION_SHIFT) +#define IOSECTION_SIZE BIT(IOSECTION_SHIFT) #define IOSECTION_MASK (~(IOSECTION_SIZE - 1)) /* * supersection address mask and size definitions. */ #define IOSUPER_SHIFT 24 -#define IOSUPER_SIZE (1UL IOSUPER_SHIFT) +#define IOSUPER_SIZE BIT(IOSUPER_SHIFT) #define IOSUPER_MASK (~(IOSUPER_SIZE - 1)) #define PTRS_PER_IOPGD (1UL (32 - IOPGD_SHIFT)) @@ -41,14 +43,14 @@ * small page address mask and size definitions. */ #define IOPTE_SHIFT12 -#define IOPTE_SIZE (1UL IOPTE_SHIFT) +#define IOPTE_SIZE BIT(IOPTE_SHIFT) #define IOPTE_MASK (~(IOPTE_SIZE - 1)) /* * large page address mask and size definitions. */ #define IOLARGE_SHIFT 16 -#define IOLARGE_SIZE (1UL IOLARGE_SHIFT) +#define IOLARGE_SIZE BIT(IOLARGE_SHIFT) #define IOLARGE_MASK (~(IOLARGE_SIZE - 1)) #define PTRS_PER_IOPTE (1UL (IOPGD_SHIFT - IOPTE_SHIFT)) @@ -72,16 +74,16 @@ static inline phys_addr_t omap_iommu_translate(u32 d, u32 va, u32 mask) /* * some descriptor attributes. */ -#define IOPGD_TABLE(1 0) -#define IOPGD_SECTION (2 0) -#define IOPGD_SUPER(1 18 | 2 0) +#define IOPGD_TABLE(1) +#define IOPGD_SECTION (2) +#define IOPGD_SUPER(BIT(18) | IOPGD_SECTION) #define iopgd_is_table(x) (((x) 3) == IOPGD_TABLE) #define iopgd_is_section(x)(((x) (1 18 | 3)) == IOPGD_SECTION) #define iopgd_is_super(x) (((x) (1 18 | 3)) == IOPGD_SUPER) -#define IOPTE_SMALL(2 0) -#define IOPTE_LARGE(1 0) +#define IOPTE_SMALL(2) +#define IOPTE_LARGE(1) #define iopte_is_small(x) (((x) 2) == IOPTE_SMALL) #define iopte_is_large(x) (((x) 3) == IOPTE_LARGE) -- 2.4.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 09/11] iommu/omap: Use BIT(x) macros in omap-iommu.h
Switch to using the BIT(x) macros in omap-iommu.h where possible. This eliminates the following checkpatch check warning: CHECK: Prefer using the BIT macro A couple of the warnings were ignored for better readability of the bit-shift for the different values. Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu.h | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h index 5b98408c18bf..a656df2f9e03 100644 --- a/drivers/iommu/omap-iommu.h +++ b/drivers/iommu/omap-iommu.h @@ -13,6 +13,8 @@ #ifndef _OMAP_IOMMU_H #define _OMAP_IOMMU_H +#include linux/bitops.h + #define for_each_iotlb_cr(obj, n, __i, cr) \ for (__i = 0; \ (__i (n)) (cr = __iotlb_read_cr((obj), __i), true); \ @@ -96,11 +98,11 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev) * MMU Register bit definitions */ /* IRQSTATUS IRQENABLE */ -#define MMU_IRQ_MULTIHITFAULT (1 4) -#define MMU_IRQ_TABLEWALKFAULT (1 3) -#define MMU_IRQ_EMUMISS(1 2) -#define MMU_IRQ_TRANSLATIONFAULT (1 1) -#define MMU_IRQ_TLBMISS(1 0) +#define MMU_IRQ_MULTIHITFAULT BIT(4) +#define MMU_IRQ_TABLEWALKFAULT BIT(3) +#define MMU_IRQ_EMUMISSBIT(2) +#define MMU_IRQ_TRANSLATIONFAULT BIT(1) +#define MMU_IRQ_TLBMISSBIT(0) #define __MMU_IRQ_FAULT\ (MMU_IRQ_MULTIHITFAULT | MMU_IRQ_EMUMISS | MMU_IRQ_TRANSLATIONFAULT) @@ -112,16 +114,16 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev) /* MMU_CNTL */ #define MMU_CNTL_SHIFT 1 #define MMU_CNTL_MASK (7 MMU_CNTL_SHIFT) -#define MMU_CNTL_EML_TLB (1 3) -#define MMU_CNTL_TWL_EN(1 2) -#define MMU_CNTL_MMU_EN(1 1) +#define MMU_CNTL_EML_TLB BIT(3) +#define MMU_CNTL_TWL_ENBIT(2) +#define MMU_CNTL_MMU_ENBIT(1) /* CAM */ #define MMU_CAM_VATAG_SHIFT12 #define MMU_CAM_VATAG_MASK \ ((~0UL MMU_CAM_VATAG_SHIFT) MMU_CAM_VATAG_SHIFT) -#define MMU_CAM_P (1 3) -#define MMU_CAM_V (1 2) +#define MMU_CAM_P BIT(3) +#define MMU_CAM_V BIT(2) #define MMU_CAM_PGSZ_MASK 3 #define MMU_CAM_PGSZ_1M(0 0) #define MMU_CAM_PGSZ_64K (1 0) @@ -134,9 +136,9 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev) ((~0UL MMU_RAM_PADDR_SHIFT) MMU_RAM_PADDR_SHIFT) #define MMU_RAM_ENDIAN_SHIFT 9 -#define MMU_RAM_ENDIAN_MASK(1 MMU_RAM_ENDIAN_SHIFT) +#define MMU_RAM_ENDIAN_MASKBIT(MMU_RAM_ENDIAN_SHIFT) #define MMU_RAM_ENDIAN_LITTLE (0 MMU_RAM_ENDIAN_SHIFT) -#define MMU_RAM_ENDIAN_BIG (1 MMU_RAM_ENDIAN_SHIFT) +#define MMU_RAM_ENDIAN_BIG BIT(MMU_RAM_ENDIAN_SHIFT) #define MMU_RAM_ELSZ_SHIFT 7 #define MMU_RAM_ELSZ_MASK (3 MMU_RAM_ELSZ_SHIFT) @@ -145,7 +147,7 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev) #define MMU_RAM_ELSZ_32(2 MMU_RAM_ELSZ_SHIFT) #define MMU_RAM_ELSZ_NONE (3 MMU_RAM_ELSZ_SHIFT) #define MMU_RAM_MIXED_SHIFT6 -#define MMU_RAM_MIXED_MASK (1 MMU_RAM_MIXED_SHIFT) +#define MMU_RAM_MIXED_MASK BIT(MMU_RAM_MIXED_SHIFT) #define MMU_RAM_MIXED MMU_RAM_MIXED_MASK #define MMU_GP_REG_BUS_ERR_BACK_EN 0x1 -- 2.4.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 07/11] iommu/omap: Remove unnecessary error traces on alloc failures
Fix couple of checkpatch warnings of the type, WARNING: Possible unnecessary 'out of memory' message Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 0fc00f31c39d..4328d9855edb 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -1093,16 +1093,12 @@ static struct iommu_domain *omap_iommu_domain_alloc(unsigned type) return NULL; omap_domain = kzalloc(sizeof(*omap_domain), GFP_KERNEL); - if (!omap_domain) { - pr_err(kzalloc failed\n); + if (!omap_domain) goto out; - } omap_domain-pgtable = kzalloc(IOPGD_TABLE_SIZE, GFP_KERNEL); - if (!omap_domain-pgtable) { - pr_err(kzalloc failed\n); + if (!omap_domain-pgtable) goto fail_nomem; - } /* * should never fail, but please keep this around to ensure -- 2.4.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/11] Some OMAP IOMMU cleanup patches
Hi Joerg, The following series includes minor cleanup patches and checkpatch fixes to the OMAP IOMMU driver. The first 5 patches do some cleanup and some debugfs code rearrangement, while the last 6 patches deal with the stricter checkpatch warnings/checks. The series is baselined on 4.2-rc3 and should apply fine on any 4.2-rc. regards Suman Suman Anna (11): Documentation: dt: Add #iommu-cells info to OMAP iommu bindings iommu/omap: Remove all module references iommu/omap: Move debugfs functions to omap-iommu-debug.c iommu/omap: Protect omap-iopgtable.h against double inclusion iommu/omap: Remove unused union fields iommu/omap: Remove trailing semi-colon from a macro iommu/omap: Remove unnecessary error traces on alloc failures iommu/omap: Use BIT(x) macros in omap-iopgtable.h iommu/omap: Use BIT(x) macros in omap-iommu.h iommu/omap: Align code with open parenthesis iommu/omap: Split multiple assignments into separate lines .../devicetree/bindings/iommu/ti,omap-iommu.txt| 6 + drivers/iommu/omap-iommu-debug.c | 113 +++- drivers/iommu/omap-iommu.c | 204 +++-- drivers/iommu/omap-iommu.h | 79 drivers/iommu/omap-iopgtable.h | 27 ++- 5 files changed, 197 insertions(+), 232 deletions(-) -- 2.4.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/11] iommu/omap: Split multiple assignments into separate lines
Use separate assignments for assigning the same value into different variables. This fixes the following check warning generated with the checkpatch --strict option: CHECK: multiple assignments should be avoided Signed-off-by: Suman Anna s-a...@ti.com --- drivers/iommu/omap-iommu.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index 36d0033c2ccb..fe742c01a4f2 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -1044,7 +1044,8 @@ omap_iommu_attach_dev(struct iommu_domain *domain, struct device *dev) goto out; } - omap_domain-iommu_dev = arch_data-iommu_dev = oiommu; + omap_domain-iommu_dev = oiommu; + arch_data-iommu_dev = oiommu; omap_domain-dev = dev; oiommu-domain = domain; @@ -1069,7 +1070,8 @@ static void _omap_iommu_detach_dev(struct omap_iommu_domain *omap_domain, omap_iommu_detach(oiommu); - omap_domain-iommu_dev = arch_data-iommu_dev = NULL; + omap_domain-iommu_dev = NULL; + arch_data-iommu_dev = NULL; omap_domain-dev = NULL; oiommu-domain = NULL; } -- 2.4.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/11] Documentation: dt: Add #iommu-cells info to OMAP iommu bindings
The OMAP IOMMU bindings is updated to reflect the required #iommu-cells property. Signed-off-by: Suman Anna s-a...@ti.com --- Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt index 42531dc387aa..869699925fd5 100644 --- a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -8,6 +8,11 @@ Required properties: - ti,hwmods : Name of the hwmod associated with the IOMMU instance - reg: Address space for the configuration registers - interrupts : Interrupt specifier for the IOMMU instance +- #iommu-cells : Should be 0. OMAP IOMMUs are all single-master devices, + and needs no additional data in the pargs specifier. Please + also refer to the generic bindings document for more info + on this property, + Documentation/devicetree/bindings/iommu/iommu.txt Optional properties: - ti,#tlb-entries : Number of entries in the translation look-aside buffer. @@ -18,6 +23,7 @@ Optional properties: Example: /* OMAP3 ISP MMU */ mmu_isp: mmu@480bd400 { + #iommu-cells = 0; compatible = ti,omap2-iommu; reg = 0x480bd400 0x80; interrupts = 24; -- 2.4.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 0/2] Add missing #iommu-cells on IOMMU nodes
Hi Tony, This series adds the #iommu-cells property to the existing IOMMU nodes on OMAP4 OMAP5. It was already fixed for OMAP3 in commit 2055088b5e17 (ARM: dts: omap3: Add #iommu-cells to isp and iva iommu). OMAP4 and OMAP5 do not yet have users for these IOMMUs (remoteproc nodes), so the warning as seen with the fix added for OMAP3 is not seen yet, but will as soon as a user is added. Patches based on 4.2-rc1. regards Suman Suman Anna (2): ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs arch/arm/boot/dts/omap4.dtsi | 2 ++ arch/arm/boot/dts/omap5.dtsi | 2 ++ 2 files changed, 4 insertions(+) -- 2.4.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 2/2] ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes for OMAP5 platforms. This property is required as per the generic iommu binding. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/boot/dts/omap5.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 7d24ae0306b5..c8fd648a7108 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -612,6 +612,7 @@ reg = 0x4a066000 0x100; interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH; ti,hwmods = mmu_dsp; + #iommu-cells = 0; }; mmu_ipu: mmu@55082000 { @@ -619,6 +620,7 @@ reg = 0x55082000 0x100; interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH; ti,hwmods = mmu_ipu; + #iommu-cells = 0; ti,iommu-bus-err-back; }; -- 2.4.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 1/2] ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs
Add missing #iommu-cells property to the DSP and IPU IOMMU nodes for OMAP4 platforms. This property is required as per the generic iommu binding. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/boot/dts/omap4.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index f884d6adb71e..7d31c6ff246f 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -551,6 +551,7 @@ reg = 0x4a066000 0x100; interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH; ti,hwmods = mmu_dsp; + #iommu-cells = 0; }; mmu_ipu: mmu@55082000 { @@ -558,6 +559,7 @@ reg = 0x55082000 0x100; interrupts = GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH; ti,hwmods = mmu_ipu; + #iommu-cells = 0; ti,iommu-bus-err-back; }; -- 2.4.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] ARM: OMAP2+: Remove module references from IOMMU machine layer
The OMAP IOMMU driver has been adapted to the IOMMU framework for a while now, and it no longer supports being built as a module. Cleanup all the module related references both from the code and in the build. While at it, also relocate a comment around the initcall to avoid a checkpatch strict warning about using a blank line after function/struct/union/enum declarations. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/mach-omap2/Makefile | 3 +-- arch/arm/mach-omap2/omap-iommu.c | 13 + 2 files changed, 2 insertions(+), 14 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 903c85be2897..d4579f856b25 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -234,8 +234,7 @@ obj-$(CONFIG_SOC_DRA7XX)+= omap_hwmod_7xx_data.o # EMU peripherals obj-$(CONFIG_HW_PERF_EVENTS) += pmu.o -iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o -obj-y += $(iommu-m) $(iommu-y) +obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o # OMAP2420 MSDI controller integration support (MMC) obj-$(CONFIG_SOC_OMAP2420) += msdi.o diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c index 4068350f9059..8867eb4025bf 100644 --- a/arch/arm/mach-omap2/omap-iommu.c +++ b/arch/arm/mach-omap2/omap-iommu.c @@ -11,7 +11,6 @@ */ #include linux/of.h -#include linux/module.h #include linux/platform_device.h #include linux/err.h #include linux/slab.h @@ -63,15 +62,5 @@ static int __init omap_iommu_init(void) return omap_hwmod_for_each_by_class(mmu, omap_iommu_dev_init, NULL); } -/* must be ready before omap3isp is probed */ omap_subsys_initcall(omap_iommu_init); - -static void __exit omap_iommu_exit(void) -{ - /* Do nothing */ -} -module_exit(omap_iommu_exit); - -MODULE_AUTHOR(Hiroshi DOYU); -MODULE_DESCRIPTION(omap iommu: omap device registration); -MODULE_LICENSE(GPL v2); +/* must be ready before omap3isp is probed */ -- 2.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] add pwm capability to dm816x
Brian, On 06/15/2015 02:32 PM, Kristo, Tero wrote: On 06/15/2015 09:36 PM, Brian Hutchinson wrote: Clocks 4-7 are capable of PWM output on dm816x. This adds the pwm capability to those timers. Use checkpatch pls, I see lots of whitespace errors. Also, I don't think Mike / Stephen care about this patch, as it is against omap hwmod data only. The capabilities should be added to the DT nodes, not to the hwmods. The hwmod timer capabilities are needed only for non-DT SoCs, and dm816x is DT boot only. regards Suman -Tero Cc: Paul Walmsley p...@pwsan.com mailto:p...@pwsan.com Cc: Tero Kristo t-kri...@ti.com mailto:t-kri...@ti.com Cc: Tony Lindgren t...@atomide.com mailto:t...@atomide.com Signed-off-by: Brian Hutchinson b.hutch...@gmail.com mailto:b.hutch...@gmail.commailto:t...@atomide.com --- arch/arm/mach-omap2/omap_hwmod_81xx_data.c_orig 2015-06-15 13:20:43.174343431 -0400 +++ arch/arm/mach-omap2/omap_hwmod_81xx_data.c 2015-06-15 13:34:51.770551392 -0400 @@ -546,6 +546,14 @@ static struct omap_timer_capability_dev_ .timer_capability = OMAP_TIMER_ALWON, }; +/* pwm timers dev attribute. + * timers 4-7 may be used for PWM output - see datasheet timer terminal + * functions table + */ +static struct omap_timer_capability_dev_attr capability_pwm_dev_attr = { + .timer_capability = OMAP_TIMER_ALWON | OMAP_TIMER_HAS_PWM, +}; + static struct omap_hwmod dm816x_timer1_hwmod = { .name = timer1, .clkdm_name = alwon_l3s_clkdm, @@ -619,7 +627,7 @@ static struct omap_hwmod dm816x_timer4_h .modulemode = MODULEMODE_SWCTRL, }, }, - .dev_attr = capability_alwon_dev_attr, + .dev_attr = capability_pwm_dev_attr, .class = dm816x_timer_hwmod_class, }; @@ -640,7 +648,7 @@ static struct omap_hwmod dm816x_timer5_h .modulemode = MODULEMODE_SWCTRL, }, }, - .dev_attr = capability_alwon_dev_attr, + .dev_attr = capability_pwm_dev_attr, .class = dm816x_timer_hwmod_class, }; @@ -661,7 +669,7 @@ static struct omap_hwmod dm816x_timer6_h .modulemode = MODULEMODE_SWCTRL, }, }, - .dev_attr = capability_alwon_dev_attr, + .dev_attr = capability_pwm_dev_attr, .class = dm816x_timer_hwmod_class, }; @@ -682,7 +690,7 @@ static struct omap_hwmod dm816x_timer7_h .modulemode = MODULEMODE_SWCTRL, }, }, - .dev_attr = capability_alwon_dev_attr, + .dev_attr = capability_pwm_dev_attr, .class = dm816x_timer_hwmod_class, }; -- 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: Enabling IPU on OMAP44xx
Hi Jack, On 24/04/15 19:34, Nishanth Menon wrote: On 04/24/2015 11:21 AM, Jack Mitchell wrote: I've been fighting for a week with trying to get the IPU booted over remoteproc on an OMAP4470. I feel like I've got most of the way there we do not have support for OMAP4470 on git.kernel.org. If you are interested in TI vendor kernel support, please use e2e.ti.com. ... Hi Nishanth, I understand; and booting an omap4470 isn't the issue, I've hacked in the support for booting it as it's basically the same as 4460; which is supported. It's the IPU that I'm trying to get working, which is the same across all the 44xx omap SoCs, right? I'm using the latest mainline and the logs I posted are from the git HEAD early this morning. I'm not looking for offical support, just pointers to people who may have been using mainline and the IPU, the support seems to be in there but none of the plumbing so I assume someone is probably using it otherwise it's dead code. Yeah, these are indeed used downstream in the TI product kernels, and it's just that adding the support for them has been progressing slowly upstream. There are couple of things that are wrong with your minimal patch, things that stand out 1. omap_ctrl_write_dsp_boot_addr is for DSP, not for IPU, so you need not set that. 2. omap_device_enable is not enough to release the processor resets in general, you can check the PRCM RSTCTRL registers, my bet is the processor is still in reset. 3. You also need to have an associated CMA pool with the remoteproc, and the CMA start address needs to match to that of your resource table, atleast with the current firmware images. In anycase, to be closer to use mainline sources, you would want to create a DT-based remoteproc device and not legacy style platform device. The mailbox and IOMMU support are converted to DT and should support OMAP4 in mainline already. FYI, you may want to look at the following TI trees, http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=shortlog;h=refs/heads/rpmsg-ti-linux-3.14.y (integrated remoteproc with rpmsg) or just http://git.ti.com/gitweb/?p=rpmsg/remoteproc.git;a=shortlog;h=refs/heads/rproc-linux-3.14.y (remoteproc without any rpmsg pieces) Those should boot on OMAP4, OMAP5 and DRA7 platforms provided you have the firmwares with appropriate resource tables. 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
[PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
The L3 Error handling on OMAP5 for the most part is very similar to that of OMAP4, and had leveraged common data structures and register layout definitions so far. Upon closer inspection, there are a few minor differences causing an incorrect decoding and reporting of the master NIU upon an error: 1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies 11 bits on OMAP5 as against 8 bits on OMAP4, with the master NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR field. 2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3 input sources on OMAP5. The common DEBUGSS source is at a different input on each SoC. Fix the above issues by using a OMAP5-specific compatible property and using SoC-specific data where there are differences. Cc: Nishanth Menon n...@ti.com Signed-off-by: Suman Anna s-a...@ti.com --- Some validation traces by adding couple of traces and intentionally creating L3 errors from DSP IPU by accessing invalid Timers Before Patch: OMAP4 [Correct] IPU accessing Timer4 [ 46.548095] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 46.553344] mstaddr = 0x44 mask = 0xfc masterid = 0x11 [ 46.553955] [ cut here ] [ 46.563171] WARNING: CPU: 0 PID: 4 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 46.564941] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 114.018524] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 114.023498] mstaddr = 0x20 mask = 0xfc masterid = 0x8 [ 114.028564] [ cut here ] [ 114.033233] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 114.042572] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access OMAP5 [Incorrect] IPU accessing Timer4: [ 29.579306] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 29.584550] mstaddr = 0x220 mask = 0xfc masterid = 0x8 [ 29.589705] [ cut here ] [ 29.594345] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 29.603774] 4400.ocp:L3 Custom Error: MASTER DSP TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 21.347105] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 21.352091] mstaddr = 0x100 mask = 0xfc masterid = 0x0 [ 21.357250] [ cut here ] [ 21.361896] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 21.371242] 4400.ocp:L3 Custom Error: MASTER MPU TARGET ABE (Idle): Data Access in Supervisor mode during Functional access After Patch: OMAP4 same as above OMAP5 [Corrected] IPU accessing Timer4 [ 67.896693] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 67.901940] mstaddr = 0x220 mask = 0x7e0 masterid = 0x11 [ 67.907275] [ cut here ] [ 67.911924] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 67.921357] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5 [ 24.452565] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 24.457552] mstaddr = 0x100 mask = 0x7e0 masterid = 0x8 [ 24.462798] [ cut here ] [ 24.467449] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 24.476795] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access .../devicetree/bindings/arm/omap/l3-noc.txt| 1 + arch/arm/boot/dts/omap5.dtsi | 2 +- drivers/bus/omap_l3_noc.c | 5 ++- drivers/bus/omap_l3_noc.h | 52 -- 4 files changed, 44 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt index 974624ea68f6..161448da959d 100644 --- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -6,6 +6,7 @@ provided by Arteris. Required properties: - compatible : Should be ti,omap3-l3-smx for OMAP3 family Should be ti,omap4-l3-noc for OMAP4 family + Should be ti,omap5-l3-noc for OMAP5 family Should be ti,dra7-l3-noc for DRA7 family Should be ti,am4372-l3-noc for AM43 family - reg: Contains L3 register address range for each noc domain. diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index efe5f737f39b..7d24ae0306b5 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -128,7 +128,7 @@ * hierarchy. */ ocp { - compatible = ti,omap4-l3-noc
Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On 04/24/2015 01:33 PM, Nishanth Menon wrote: On 04/24/2015 12:54 PM, Suman Anna wrote: The L3 Error handling on OMAP5 for the most part is very similar to that of OMAP4, and had leveraged common data structures and register layout definitions so far. Upon closer inspection, there are a few minor differences causing an incorrect decoding and reporting of the master NIU upon an error: 1. The L3_TARG_STDERRLOG_MSTADDR.STDERRLOG_MSTADDR occupies 11 bits on OMAP5 as against 8 bits on OMAP4, with the master NIU connID encoded in the 6 MSBs of the STDERRLOG_MSTADDR field. 2. The CLK3 FlagMux component has 1 input source on OMAP4 and 3 input sources on OMAP5. The common DEBUGSS source is at a different input on each SoC. Fix the above issues by using a OMAP5-specific compatible property and using SoC-specific data where there are differences. Cc: Nishanth Menon n...@ti.com Signed-off-by: Suman Anna s-a...@ti.com --- Some validation traces by adding couple of traces and intentionally creating L3 errors from DSP IPU by accessing invalid Timers Before Patch: OMAP4 [Correct] IPU accessing Timer4 [ 46.548095] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 46.553344] mstaddr = 0x44 mask = 0xfc masterid = 0x11 [ 46.553955] [ cut here ] [ 46.563171] WARNING: CPU: 0 PID: 4 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 46.564941] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 114.018524] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 114.023498] mstaddr = 0x20 mask = 0xfc masterid = 0x8 [ 114.028564] [ cut here ] [ 114.033233] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 114.042572] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access OMAP5 [Incorrect] IPU accessing Timer4: [ 29.579306] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 29.584550] mstaddr = 0x220 mask = 0xfc masterid = 0x8 [ 29.589705] [ cut here ] [ 29.594345] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 29.603774] 4400.ocp:L3 Custom Error: MASTER DSP TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5: [ 21.347105] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 21.352091] mstaddr = 0x100 mask = 0xfc masterid = 0x0 [ 21.357250] [ cut here ] [ 21.361896] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 21.371242] 4400.ocp:L3 Custom Error: MASTER MPU TARGET ABE (Idle): Data Access in Supervisor mode during Functional access After Patch: OMAP4 same as above OMAP5 [Corrected] IPU accessing Timer4 [ 67.896693] flagmux = 1, err_reg = 0x8000 err_src = 0xf [ 67.901940] mstaddr = 0x220 mask = 0x7e0 masterid = 0x11 [ 67.907275] [ cut here ] [ 67.911924] WARNING: CPU: 0 PID: 61 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 67.921357] 4400.ocp:L3 Custom Error: MASTER DucatiM3 TARGET L4PER3 (Idle): Data Access in User mode during Functional access DSP accessing Timer5 [ 24.452565] flagmux = 0, err_reg = 0x4 err_src = 0x2 [ 24.457552] mstaddr = 0x100 mask = 0x7e0 masterid = 0x8 [ 24.462798] [ cut here ] [ 24.467449] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:149 l3_interrupt_handler+0x280/0x388() [ 24.476795] 4400.ocp:L3 Custom Error: MASTER DSP TARGET ABE (Idle): Data Access in Supervisor mode during Functional access .../devicetree/bindings/arm/omap/l3-noc.txt| 1 + arch/arm/boot/dts/omap5.dtsi | 2 +- drivers/bus/omap_l3_noc.c | 5 ++- drivers/bus/omap_l3_noc.h | 52 -- 4 files changed, 44 insertions(+), 16 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt index 974624ea68f6..161448da959d 100644 --- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt +++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt @@ -6,6 +6,7 @@ provided by Arteris. Required properties: - compatible : Should be ti,omap3-l3-smx for OMAP3 family Should be ti,omap4-l3-noc for OMAP4 family + Should be ti,omap5-l3-noc for OMAP5 family Should be ti,dra7-l3-noc for DRA7 family Should be ti,am4372-l3-noc for AM43 family - reg: Contains L3 register address range for each noc domain. diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index efe5f737f39b..7d24ae0306b5
Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5
On 04/24/2015 02:38 PM, Nishanth Menon wrote: On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna s-a...@ti.com wrote: On 04/24/2015 01:33 PM, Nishanth Menon wrote: On 04/24/2015 12:54 PM, Suman Anna wrote: ... -static struct l3_target_data omap_l3_target_data_clk3[] = { -{0x0100, EMUSS,}, -{0x0300, DEBUG SOURCE,}, -{0x0, HOST CLK3,}, ^^ this was HOST CLK3 .. +/* OMAP5 data */ +static struct l3_target_data omap5_l3_target_data_clk3[] = { +{0x0100, L3INSTR,}, +{0x0300, DEBUGSS,}, +{0x0,HOSTCLK3,}, HOST CLK Why? I followed the convention used for the other two HOST CLKs for the so asked, if it should be HOSTspaceCLK3 Aah ok, you missed the trailing number before. In anycase, this was intentional to match HOSTCLK1 and HOSTCLK2 on OMAP4/5. Overall, the names are somewhat non-standard, some use underscores and some others strip out the underscore and do not use any spaces in between either. HOST CLK3 would be the only one to use a space for OMAP4, so I got rid of it, so hope that's ok with you. 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: [PATCH v8 0/4] hwspinlock core omap dt support
Mark, On 03/18/2015 04:57 PM, Suman Anna wrote: Hi Mark, On 03/12/2015 04:24 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Mar 5, 2015 at 4:01 AM, Suman Anna s-a...@ti.com wrote: This is the latest version of the hwspinlock dt support series, rebased onto v4.0-rc1 and addressing the long discussion on the bindings in v7 [1]. I really hope that this series can make it into 4.1. From a quick glance this looks great, thanks! Mark, Can you please provide your Acked-by for the binding documents so that Ohad can pick up the patches for the next merge window? That would be perfect. Once we'll have it I could move forward with this towards 4.1. Gentle reminder. Can you please provide your ack on the bindings in this series (Patches 1 3) for Ohad to queue up the series for 4.1. Ping again, if you can provide your ack on these bindings and the qcom hwmutex bindings, then Ohad can pick up both the series for 4.1. Both series are blocked on getting the binding acks. 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: [PATCH 2/2] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4
On 03/24/2015 01:06 PM, Paul Walmsley wrote: On Mon, 16 Mar 2015, Suman Anna wrote: GPTimer 4 is a regular timer and not a secure timer, so fix the hwmod to use the correct hwmod class (even though there are no differences in the class definition itself). Signed-off-by: Suman Anna s-a...@ti.com This one results in compiler warnings: arch/arm/mach-omap2/omap_hwmod_7xx_data.c:1776:32: warning: ‘dra7xx_timer_secure_hwmod_class’ defined but not used [-Wunused-variable] static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = { Have queued the following for v4.1. Thanks Paul. I will add it back when I post the hwmod for Timer 12, I had the Timer12 locally in my tree, so missed the warning. regards Suman - Paul From: Suman Anna s-a...@ti.com Date: Mon, 16 Mar 2015 15:54:54 -0500 Subject: [PATCH] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4 GPTimer 4 is a regular timer and not a secure timer, so fix the hwmod to use the correct hwmod class (even though there are no differences in the class definition itself). Signed-off-by: Suman Anna s-a...@ti.com [p...@pwsan.com: dropped dra7xx_timer_secure_hwmod_class and dra7xx_timer_secure_sysc to avoid compiler warnings] Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 17 + 1 file changed, 1 insertion(+), 16 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c index d0f03e73add4..701234d8db1b 100644 --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c @@ -1763,21 +1763,6 @@ static struct omap_hwmod_class dra7xx_timer_1ms_hwmod_class = { .sysc = dra7xx_timer_1ms_sysc, }; -static struct omap_hwmod_class_sysconfig dra7xx_timer_secure_sysc = { - .rev_offs = 0x, - .sysc_offs = 0x0010, - .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS | -SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET), - .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART | -SIDLE_SMART_WKUP), - .sysc_fields= omap_hwmod_sysc_type2, -}; - -static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = { - .name = timer, - .sysc = dra7xx_timer_secure_sysc, -}; - static struct omap_hwmod_class_sysconfig dra7xx_timer_sysc = { .rev_offs = 0x, .sysc_offs = 0x0010, @@ -1841,7 +1826,7 @@ static struct omap_hwmod dra7xx_timer3_hwmod = { /* timer4 */ static struct omap_hwmod dra7xx_timer4_hwmod = { .name = timer4, - .class = dra7xx_timer_secure_hwmod_class, + .class = dra7xx_timer_hwmod_class, .clkdm_name = l4per_clkdm, .main_clk = timer4_gfclk_mux, .prcm = { -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 29/35] ARM: dts: am4372: add minimal l4 bus layout with control module support
Hi Tero, On 03/20/2015 01:44 PM, Kristo, Tero wrote: This patch creates an l4_wkup interconnect for AM43xx, and moves some of the generic peripherals under it. System control module nodes are moved under this new interconnect also, and the SCM clock layout is changed to use the renamed SCM nodea as the clock provider. Signed-off-by: Tero Kristo t-kri...@ti.com --- Documentation/devicetree/bindings/arm/omap/l4.txt |1 + .../devicetree/bindings/arm/omap/prcm.txt |2 +- arch/arm/boot/dts/am4372.dtsi | 85 +++- arch/arm/boot/dts/am43xx-clocks.dtsi |2 +- arch/arm/mach-omap2/control.c |2 +- 5 files changed, 53 insertions(+), 39 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/l4.txt b/Documentation/devicetree/bindings/arm/omap/l4.txt index d333f0a..941b914 100644 --- a/Documentation/devicetree/bindings/arm/omap/l4.txt +++ b/Documentation/devicetree/bindings/arm/omap/l4.txt @@ -7,6 +7,7 @@ Required properties: Should be ti,omap2-l4-wkup for OMAP2 family l4 wkup bus Should be ti,omap3-l4-core for OMAP3 family l4 core bus Should be ti,am3-l4-wkup for AM33xx family l4 wkup bus +Should be ti,am4-l4-wkup for AM43xx family l4 wkup bus - ranges : contains the IO map range for the bus Examples: diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt b/Documentation/devicetree/bindings/arm/omap/prcm.txt index c8e2027..8af4f32 100644 --- a/Documentation/devicetree/bindings/arm/omap/prcm.txt +++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt @@ -12,7 +12,7 @@ Required properties: ti,am3-prcm ti,am3-scm ti,am4-prcm - ti,am4-scrm + ti,am4-scm ti,omap2-prcm ti,omap2-scm ti,omap3-prm diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi index 1943fc3..9ed58115 100644 --- a/arch/arm/boot/dts/am4372.dtsi +++ b/arch/arm/boot/dts/am4372.dtsi @@ -57,22 +57,6 @@ cache-level = 2; }; - am43xx_control_module: control_module@4a002000 { - compatible = syscon; - reg = 0x44e1 0x7f4; - }; - - am43xx_pinmux: pinmux@44e10800 { - compatible = ti,am437-padconf, pinctrl-single; - reg = 0x44e10800 0x31c; - #address-cells = 1; - #size-cells = 0; - #interrupt-cells = 1; - interrupt-controller; - pinctrl-single,register-width = 32; - pinctrl-single,function-mask = 0x; - }; - ocp { compatible = ti,am4372-l3-noc, simple-bus; #address-cells = 1; @@ -84,29 +68,58 @@ interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH, GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH; - prcm: prcm@44df { - compatible = ti,am4-prcm; - reg = 0x44df 0x11000; - - prcm_clocks: clocks { - #address-cells = 1; - #size-cells = 0; - }; + l4_wkup: l4_wkup@44c0 { + compatible = ti,am4-l4-wkup, simple-bus; + #address-cells = 1; + #size-cells = 1; + ranges = 0 0x44c0 0x287000; - prcm_clockdomains: clockdomains { - }; - }; + prcm: prcm@1f { + compatible = ti,am4-prcm; + reg = 0x1f 0x11000; - scrm: scrm@44e1 { - compatible = ti,am4-scrm; - reg = 0x44e1 0x2000; + prcm_clocks: clocks { + #address-cells = 1; + #size-cells = 0; + }; - scrm_clocks: clocks { - #address-cells = 1; - #size-cells = 0; + prcm_clockdomains: clockdomains { + }; }; - scrm_clockdomains: clockdomains { + scm: scm@21 { + compatible = ti,am4-scm, simple-bus; + reg = 0x21 0x1000; Any reason for choosing a different size here compared to AM335x. Also, the scrm node above has 0x2000 as size. I found that I needed to increase the size to 0x2000 here to accomodate the wkup_m3_ipc node on top of your series. The node uses IPC registers which are part of the Control module, so on AM335x, I added it as a child node of scm, but here to do the same I
Re: [PATCH 0/2] Couple of DRA7 hwmod patches on Timers
Hi Paul, Following are couple of DRA7 hwmod patches for the GPTimers. Patches based on 4.0-rc1. The first patch adds the data for timers 13 through 16, the DT nodes are already present, and when enabled without the hwmod data triggers a l3_noc interrupt and hangs the kernel boot [1]. The boot hang can also be fixed by checking the return status of pm_runtime_get_sync() in the OMAP dmtimer probe, I will post a separate fix for that. Second patch is a minor fix. Thanks. Sounds like the first one should go in for v4.0-rc fixes, and the second one can wait for v4.1? If so then could you repost the first fix to include the description of why it should go in early in the patch description (the DT nodes are already present, and when enabled without the hwmod data triggers a l3_noc interrupt and hangs the kernel boot). That should avoid anyone questioning why it would go in as a v4.0-rc fix at this point, and should help the -stable crew out. Actually, both of them can be queued for v4.1. Tony has already sent a pull request with the fixes [1] in the driver. The driver fixes will scale for all SoCs, so will fix this boot issue as well if anyone tries to enable these timers. regards Suman [1] http://marc.info/?l=linux-omapm=142661461902725w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 27/35] ARM: dts: am33xx: add minimal l4 bus layout with control module support
On 03/20/2015 05:35 PM, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [150320 14:44]: On 03/20/2015 01:44 PM, Kristo, Tero wrote: + scm: scm@21 { + compatible = ti,am3-scm, simple-bus; + reg = 0x21 0x2000; + #address-cells = 1; + #size-cells = 1; + ranges = 0 0x21 0x2000; + + am33xx_pinmux: pinmux@800 { + compatible = pinctrl-single; + reg = 0x800 0x238; + #address-cells = 1; + #size-cells = 0; + pinctrl-single,register-width = 32; + pinctrl-single,function-mask = 0x7f; + }; + + scm_conf: scm_conf@0 { + compatible = syscon; + reg = 0x0 0x7fc; Hmm, you are consolidating the am33xx_control_module and cm nodes, so is this supposed to be 0x800 or 0x7fc? I would think it should be 0x800. Seems correct to me, it's offset 0, size 0x7fc. So that's the scm_conf syscon area before pinctrl-single at 0x44c0 + 0x21 + 0. The io area for pinctrl-single starts at 0x800, so the scm_conf should be before it in the dts file. Well, I understand that it is how it was before, but we won't be mapping or covering the last register efuse_sma before the pinctrl cfg registers. Any reason for just leaving out that register? regards Suman Also, are we ordering the child nodes of scm by node names or addresses. I have to add the wkup_m3 node, and prefer ordering by addresses. Yeah address ordering makes most sense here IMO. Note that you should follow the TRM Table 2-2. L4_WKUP Peripheral Memory Map and set up things as separate devices as shown there. Pretty much each row in that table is a separate device on the interconnect. That's especially true if the device has registers like revision, sysc, syss and so on. In that case they can be clocked and idled separately. So with these changes we follow the hardware mapping, although only partially have it populated now for l4_wkup: l3 (ocp) +- l4_per +- ... | |- ... | +- l4_wkup +- prcm | |- scm | |- ... | +- ... +- ... Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 27/35] ARM: dts: am33xx: add minimal l4 bus layout with control module support
Hi Tero, On 03/20/2015 01:44 PM, Kristo, Tero wrote: This patch creates an l4_wkup interconnect for AM33xx, and moves some of the generic peripherals under it. System control module nodes are moved under this new interconnect also, and the SCM clock layout is changed to use the renamed SCM node as the clock provider. Signed-off-by: Tero Kristo t-kri...@ti.com --- Documentation/devicetree/bindings/arm/omap/l4.txt |1 + .../devicetree/bindings/arm/omap/prcm.txt |2 +- arch/arm/boot/dts/am33xx-clocks.dtsi |2 +- arch/arm/boot/dts/am33xx.dtsi | 87 +++- arch/arm/mach-omap2/control.c |2 +- 5 files changed, 51 insertions(+), 43 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/omap/l4.txt b/Documentation/devicetree/bindings/arm/omap/l4.txt index 6402022..d333f0a 100644 --- a/Documentation/devicetree/bindings/arm/omap/l4.txt +++ b/Documentation/devicetree/bindings/arm/omap/l4.txt @@ -6,6 +6,7 @@ Required properties: - compatible : Should be ti,omap2-l4 for OMAP2 family l4 core bus Should be ti,omap2-l4-wkup for OMAP2 family l4 wkup bus Should be ti,omap3-l4-core for OMAP3 family l4 core bus +Should be ti,am3-l4-wkup for AM33xx family l4 wkup bus - ranges : contains the IO map range for the bus Examples: diff --git a/Documentation/devicetree/bindings/arm/omap/prcm.txt b/Documentation/devicetree/bindings/arm/omap/prcm.txt index ef5a74b..c8e2027 100644 --- a/Documentation/devicetree/bindings/arm/omap/prcm.txt +++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt @@ -10,7 +10,7 @@ documentation about the individual clock/clockdomain nodes. Required properties: - compatible:Must be one of: ti,am3-prcm - ti,am3-scrm + ti,am3-scm ti,am4-prcm ti,am4-scrm ti,omap2-prcm diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi b/arch/arm/boot/dts/am33xx-clocks.dtsi index 712edce..236c78a 100644 --- a/arch/arm/boot/dts/am33xx-clocks.dtsi +++ b/arch/arm/boot/dts/am33xx-clocks.dtsi @@ -7,7 +7,7 @@ * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -scrm_clocks { +scm_clocks { sys_clkin_ck: sys_clkin_ck { #clock-cells = 0; compatible = ti,mux-clock; diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index acd3705..8d26261 100644 --- a/arch/arm/boot/dts/am33xx.dtsi +++ b/arch/arm/boot/dts/am33xx.dtsi @@ -83,20 +83,6 @@ }; }; - am33xx_control_module: control_module@4a002000 { - compatible = syscon; - reg = 0x44e1 0x7fc; - }; - - am33xx_pinmux: pinmux@44e10800 { - compatible = pinctrl-single; - reg = 0x44e10800 0x0238; - #address-cells = 1; - #size-cells = 0; - pinctrl-single,register-width = 32; - pinctrl-single,function-mask = 0x7f; - }; - /* * XXX: Use a flat representation of the AM33XX interconnect. * The real AM33XX interconnect network is quite complex. Since @@ -111,37 +97,58 @@ ranges; ti,hwmods = l3_main; - prcm: prcm@44e0 { - compatible = ti,am3-prcm; - reg = 0x44e0 0x4000; - - prcm_clocks: clocks { - #address-cells = 1; - #size-cells = 0; - }; + l4_wkup: l4_wkup@44c0 { + compatible = ti,am3-l4-wkup, simple-bus; + #address-cells = 1; + #size-cells = 1; + ranges = 0 0x44c0 0x28; - prcm_clockdomains: clockdomains { - }; - }; + prcm: prcm@20 { + compatible = ti,am3-prcm; + reg = 0x20 0x4000; - scrm: scrm@44e1 { - compatible = ti,am3-scrm; - reg = 0x44e1 0x2000; + prcm_clocks: clocks { + #address-cells = 1; + #size-cells = 0; + }; - scrm_clocks: clocks { - #address-cells = 1; - #size-cells = 0; + prcm_clockdomains: clockdomains { + }; }; - scrm_clockdomains: clockdomains { + scm: scm@21 { + compatible = ti,am3-scm, simple-bus; +
Re: [PATCH v8 0/4] hwspinlock core omap dt support
Hi Mark, On 03/12/2015 04:24 AM, Ohad Ben-Cohen wrote: Hi Suman, On Thu, Mar 5, 2015 at 4:01 AM, Suman Anna s-a...@ti.com wrote: This is the latest version of the hwspinlock dt support series, rebased onto v4.0-rc1 and addressing the long discussion on the bindings in v7 [1]. I really hope that this series can make it into 4.1. From a quick glance this looks great, thanks! Mark, Can you please provide your Acked-by for the binding documents so that Ohad can pick up the patches for the next merge window? That would be perfect. Once we'll have it I could move forward with this towards 4.1. Gentle reminder. Can you please provide your ack on the bindings in this series (Patches 1 3) for Ohad to queue up the series for 4.1. Thanks 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
[PATCH 2/2] ARM: OMAP: dmtimer: disable pm runtime on remove
Disable the pm_runtime of the device upon remove. This is added to balance the pm_runtime_enable() invoked in the probe. Signed-off-by: Suman Anna s-a...@ti.com --- arch/arm/plat-omap/dmtimer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index f32c74c0e1de..8ca94d379bc3 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -910,6 +910,8 @@ static int omap_dm_timer_remove(struct platform_device *pdev) } spin_unlock_irqrestore(dm_timer_lock, flags); + pm_runtime_disable(pdev-dev); + return ret; } -- 2.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Couple of dmtimer fixes
Hi Tony, Please find couple of non-urgent fixes to the OMAP dmtimer driver. The patches are based on 4.0-rc1. The first patch is a fix for the issue I reported earlier on the DRA7 dmtimer hwmod patches [1]. DRA7 has timers 13 through 16 disabled in DT currently, and enabling any of them would cause a kernel hang. This fix properly checks the pm_runtime_get_sync() calls in the OMAP dmtimer driver irrespective of whether the hwmods are added or not. In the case that they are not added, the runtime_pm calls should return the value as returned from _od_fail_runtime_resume(), and the probe should bail out properly fixing the boot hang. Second patch is a minor fix that balances the pm_runtime_enable() call in probe with pm_runtime_disable() call in remove, so that the devices can be bound again properly after doing an unbind through sysfs. regards Suman [1] http://marc.info/?l=linux-omapm=142653933112526w=2 Suman Anna (2): ARM: OMAP: dmtimer: check for pm_runtime_get_sync() failure ARM: OMAP: dmtimer: disable pm runtime on remove arch/arm/plat-omap/dmtimer.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) -- 2.3.2 -- 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