Re: [PATCH 0/4] Cleanup legacy OMAP IOMMU device creation

[Suman Anna]

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 1/2] ARM: OMAP2+: Remove legacy mailbox device instantiation

[Suman Anna]

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

[Suman Anna]

On 10/21/2015 11:42 PM, Jassi Brar wrote:
> On 22 October 2015 at 05:35, Suman Anna  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 v3 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Suman Anna]

Hi Jassi,

On 10/20/2015 11:44 PM, Jassi Brar wrote:
> On Wed, Sep 23, 2015 at 5:44 AM, Dave Gerlach  wrote:
>> 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

[Suman Anna]

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

[Suman Anna]

Hi Tony,

On 10/12/2015 04:43 PM, Tony Lindgren wrote:
> * Suman Anna  [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 
>> ---
>>  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 04/11] arm: omap2: timer: provide generic sync32k_timer_init function

[Suman Anna]

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

[Suman Anna]

On 10/06/2015 12:14 PM, Felipe Balbi wrote:
> 
> Hi,
> 
> Suman Anna  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 
>>>>>>> ---
>>>>>>>
>>>>>>> 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] arm: omap2: timer: don't disable our timers

[Suman Anna]

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

[Suman Anna]

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] arm: omap2: timer: don't disable our timers

[Suman Anna]

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 3/4] ARM: dts: DRA7: Add timer12 node

[Suman Anna]

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

[Suman Anna]

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

[Suman Anna]

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&m=144372799601354&w=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 2/4] ARM: OMAP2+: timer: Remove secure timer for DRA7xx HS devices

[Suman Anna]

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 
---
 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 4/4] ARM: DRA7: hwmod: Add data for GPTimer 12

[Suman Anna]

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 
---
 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  = &dra7xx_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 = &dra7xx_l4_wkup_hwmod,
+   .slave  = &dra7xx_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 = &dra7xx_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 = {
+   &dra7xx_l4_wkup__timer12,
+   NULL,
+};
+
+/* SoC variant specific hwmod links */
 static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
&dra7xx_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] arm: omap2: timer: don't disable our timers

[Suman Anna]

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, &device_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 1/4] ARM: OMAP: dmtimer: check for fixed timers during config

[Suman Anna]

On 10/05/2015 11:58 AM, Tony Lindgren wrote:
> * Suman Anna  [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 1/4] ARM: OMAP: dmtimer: check for fixed timers during config

[Suman Anna]

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

[REPOST PATCH 1/4] ARM: dts: DRA7: Add dsp1_system syscon node

[Suman Anna]

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

[Suman Anna]

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 
---
 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 = <&dsp1_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 = <&dsp1_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

[Suman Anna]

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 
---
 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 = <&dsp2_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 = <&dsp2_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

[Suman Anna]

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

[Suman Anna]

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&m=143752332808524&w=2
[2] http://marc.info/?l=linux-omap&m=144382697928741&w=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 0/2] DRA7 DSP MMU config support

[Suman Anna]

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&m=144356627831318&w=2
[6] http://marc.info/?l=linux-omap&m=143752332808524&w=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

[REPOST PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Suman Anna]

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 
---
 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(&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_dom

[REPOST PATCH 1/2] Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs

[Suman Anna]

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 
---
 .../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 = <&dsp2_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 = <&dsp2_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

Re: [PATCH] clk: ti: dflt: fix enable_reg validity check

[Suman Anna]

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

[PATCH 3/4] ARM: dts: DRA7: Add timer12 node

[Suman Anna]

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 
---
 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 2/4] ARM: OMAP2+: timer: Remove secure timer for DRA7xx devices

[Suman Anna]

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 
---
 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 1/4] ARM: OMAP: dmtimer: check for fixed timers during config

[Suman Anna]

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

[Suman Anna]

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 4/4] ARM: DRA7: hwmod: Add data for GPTimer 12

[Suman Anna]

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 
---
 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  = &dra7xx_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 = &dra7xx_l4_wkup_hwmod,
+   .slave  = &dra7xx_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 = &dra7xx_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 = {
+   &dra7xx_l4_wkup__timer12,
+   NULL,
+};
+
+/* SoC variant specific hwmod links */
 static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
&dra7xx_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] clk: ti: dflt: fix enable_reg validity check

[Suman Anna]

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

[PATCH 0/5] Add DRA7 sub-mailboxes for 4.4

[Suman Anna]

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 3/5] ARM: dts: dra7-evm: Enable the system mailboxes 5 and 6

[Suman Anna]

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 
---
 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 = <&dcan1_pins_sleep>;
pinctrl-2 = <&dcan1_pins_default>;
 };
+
+&mailbox5 {
+   status = "okay";
+   mbox_ipu1_ipc3x: mbox_ipu1_ipc3x {
+   status = "okay";
+   };
+   mbox_dsp1_ipc3x: mbox_dsp1_ipc3x {
+   status = "okay";
+   };
+};
+
+&mailbox6 {
+   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

[Suman Anna]

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 
---
 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 @@
};
};
 };
+
+&mailbox5 {
+   status = "okay";
+   mbox_ipu1_ipc3x: mbox_ipu1_ipc3x {
+   status = "okay";
+   };
+   mbox_dsp1_ipc3x: mbox_dsp1_ipc3x {
+   status = "okay";
+   };
+};
+
+&mailbox6 {
+   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 1/5] ARM: dts: DRA74x: Add IPC sub-mailbox nodes for all IPUs & DSPs

[Suman Anna]

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 
---
 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 @@
 <&dss_video2_clk>;
clock-names = "fck", "video1_clk", "video2_clk";
 };
+
+&mailbox5 {
+   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";
+   };
+};
+
+&mailbox6 {
+   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 2/5] ARM: dts: DRA72x: Add IPC sub-mailbox nodes for IPU1, IPU2 & DSP1

[Suman Anna]

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 
---
 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 @@
 <&dss_video1_clk>;
clock-names = "fck", "video1_clk";
 };
+
+&mailbox5 {
+   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";
+   };
+};
+
+&mailbox6 {
+   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 5/5] ARM: dts: beagle-x15: Enable the system mailboxes 5 and 6

[Suman Anna]

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 
---
 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 @@
 &pcie1 {
gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
 };
+
+&mailbox5 {
+   status = "okay";
+   mbox_ipu1_ipc3x: mbox_ipu1_ipc3x {
+   status = "okay";
+   };
+   mbox_dsp1_ipc3x: mbox_dsp1_ipc3x {
+   status = "okay";
+   };
+};
+
+&mailbox6 {
+   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 3/4] ARM: OMAP4: hwmod data: Remove legacy IOMMU attr and addrs

[Suman Anna]

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 
---
 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 = &omap44xx_l3_main_2_hwmod,
.slave  = &omap44xx_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   = &mmu_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 = &omap44xx_l4_cfg_hwmod,
.slave  = &omap44xx_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   = &mmu_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 4/4] ARM: OMAP2+: Remove omap_mmu_dev_attr structure

[Suman Anna]

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 
---
 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 2/4] ARM: OMAP3: hwmod data: Remove legacy IOMMU data

[Suman Anna]

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 
---
 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 = &omap3xxx_l4_core_hwmod,
.slave  = &omap3xxx_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  = &omap3xxx_mmu_hwmod_class,
-   .mpu_irqs   = omap3xxx_mmu_isp_irqs,
.main_clk   = "cam_ick",
-   .dev_attr   = &mmu_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 = &omap3xxx_l3_main_hwmod,
.slave  = &omap3xxx_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  = &omap3xxx_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   = &mmu_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 1/4] ARM: OMAP2+: Remove legacy device instantiation of IOMMUs

[Suman Anna]

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 
---
 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 
- *
- * 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 0/4] Cleanup legacy OMAP IOMMU device creation

[Suman Anna]

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

[PATCH 2/2] ARM: OMAP3: hwmod data: Remove legacy mailbox data and addrs

[Suman Anna]

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 
---
 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 = &omap3xxx_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  = &omap3xxx_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   = &omap3xxx_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 = &omap3xxx_l4_core_hwmod,
.slave  = &omap3xxx_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 1/2] ARM: OMAP2+: Remove legacy mailbox device instantiation

[Suman Anna]

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

[Suman Anna]

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 1/2] ARM: OMAP4: hwmod data: Remove spinlock hwmod addrs

[Suman Anna]

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 
---
 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 = &omap44xx_l4_cfg_hwmod,
.slave  = &omap44xx_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

[PATCH 2/2] ARM: DRA7: hwmod data: Remove spinlock hwmod addrs

[Suman Anna]

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 
---
 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 = &dra7xx_l4_cfg_hwmod,
.slave  = &dra7xx_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 0/2] OMAP hwspinlock hwmod cleanup

[Suman Anna]

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

Re: [PATCH 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Suman Anna]

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

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

Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Suman Anna]

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  [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 1/2] ARM: OMAP2+: Remove legacy OMAP3 ISP instantiation

[Suman Anna]

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 v2 1/3] mailbox/omap: Add ti,mbox-send-noirq quirk to fix AM33xx CPU Idle

[Suman Anna]

Hi Tony,

On 08/05/2015 05:28 AM, Tony Lindgren wrote:
> * Dave Gerlach  [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 0/2] DRA7 DSP MMU config support

[Suman Anna]

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 00/11] Some OMAP IOMMU cleanup patches

[Suman Anna]

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 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Suman Anna]

Hi Tony,

On 07/23/2015 11:30 PM, Tony Lindgren wrote:
> * Suman Anna  [150723 09:25]:
>> Hi Tony,
>>
>> On 07/23/2015 02:24 AM, Tony Lindgren wrote:
>>> * Suman Anna  [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 

Re: [PATCH 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Suman Anna]

Hi Tony,

On 07/23/2015 02:24 AM, Tony Lindgren wrote:
> * Suman Anna  [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

[Suman Anna]

Hi Tony,

On 07/22/2015 12:26 AM, Tony Lindgren wrote:
> * Suman Anna  [150721 16:58]:
>> --- 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)
> 
> 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

[PATCH 2/4] ARM: dts: DRA74x: Add dsp2_system syscon node

[Suman Anna]

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 
---
 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 4/4] ARM: dts: DRA74x: Add IOMMU nodes for DSP2

[Suman Anna]

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 
---
 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 = ;
+   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 = ;
+   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 3/4] ARM: dts: DRA7: Add common IOMMU nodes

[Suman Anna]

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 
---
 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 = ;
+   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 = ;
+   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 = ;
+   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.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

[Suman Anna]

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 
---
 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 0/4] Add DRA7 IOMMU DT nodes

[Suman Anna]

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-omap&m=143752295508435&w=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

[PATCH 0/2] DRA7 DSP MMU config support

[Suman Anna]

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 2/2] iommu/omap: Add support for configuring dsp iommus on DRA7xx

[Suman Anna]

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 
---
 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 
 #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(&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_dom

[PATCH 1/2] Documentation: dt: Update OMAP iommu bindings for DRA7 DSPs

[Suman Anna]

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 
---
 .../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 = <&dsp2_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 = <&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

Re: [PATCH 02/11] iommu/omap: Remove all module references

[Suman Anna]

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

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 04/11] iommu/omap: Protect omap-iopgtable.h against double inclusion

[Suman Anna]

Protect the omap-pgtable.h header against double inclusion in
source code by using the standard include guard mechanism.

Signed-off-by: Suman Anna 
---
 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

[Suman Anna]

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 
---
 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 
-#include 
 #include 
 #include 
 #include 
@@ -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

[Suman Anna]

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 
---
 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 06/11] iommu/omap: Remove trailing semi-colon from a macro

[Suman Anna]

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

[Suman Anna]

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 
---
 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 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -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
+++ 

[PATCH 05/11] iommu/omap: Remove unused union fields

[Suman Anna]

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

[Suman Anna]

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 
---
 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 
+
 /*
  * "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

[Suman Anna]

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 
---
 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 
+
 #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 00/11] Some OMAP IOMMU cleanup patches

[Suman Anna]

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

[Suman Anna]

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

[Suman Anna]

The OMAP IOMMU bindings is updated to reflect the required #iommu-cells
property.

Signed-off-by: Suman Anna 
---
 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 07/11] iommu/omap: Remove unnecessary error traces on alloc failures

[Suman Anna]

Fix couple of checkpatch warnings of the type,
"WARNING: Possible unnecessary 'out of memory' message"

Signed-off-by: Suman Anna 
---
 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

Re: [PATCH] ARM: OMAP2+: Remove module references from IOMMU machine layer

[Suman Anna]

Hi Tony,

On 07/16/2015 02:16 AM, Tony Lindgren wrote:
> * Suman Anna  [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-omap&m=143705130631733&w=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] ARM: OMAP2+: Remove module references from IOMMU machine layer

[Suman Anna]

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 
---
 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 
-#include 
 #include 
 #include 
 #include 
@@ -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

[PATCH 2/2] ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs

[Suman Anna]

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 
---
 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 = ;
ti,hwmods = "mmu_dsp";
+   #iommu-cells = <0>;
};
 
mmu_ipu: mmu@55082000 {
@@ -619,6 +620,7 @@
reg = <0x55082000 0x100>;
interrupts = ;
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 0/2] Add missing #iommu-cells on IOMMU nodes

[Suman Anna]

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 1/2] ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs

[Suman Anna]

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 
---
 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 = ;
ti,hwmods = "mmu_dsp";
+   #iommu-cells = <0>;
};
 
mmu_ipu: mmu@55082000 {
@@ -558,6 +559,7 @@
reg = <0x55082000 0x100>;
interrupts = ;
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

Re: [PATCH 1/1] add pwm capability to dm816x

[Suman Anna]

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 mailto:p...@pwsan.com>>
>> Cc: Tero Kristo mailto:t-kri...@ti.com>>
>> Cc: Tony Lindgren mailto:t...@atomide.com>>
>> Signed-off-by: Brian Hutchinson > >
>>
>> --- 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

[Suman Anna]

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

Re: [PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5

[Suman Anna]

On 04/24/2015 02:38 PM, Nishanth Menon wrote:
> On Fri, Apr 24, 2015 at 2:10 PM, Suman Anna  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 HOSTCLK3

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] bus: omap_l3_noc: Fix master id address decoding for OMAP5

[Suman Anna]

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 
>> Signed-off-by: Suman Anna 
>> ---
>>
>> 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/devicetre

[PATCH] bus: omap_l3_noc: Fix master id address decoding for OMAP5

[Suman Anna]

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 
Signed-off-by: Suman Anna 
---

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

Re: [PATCH v8 0/4] hwspinlock core & omap dt support

[Suman Anna]

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  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: [PATCHv5 29/35] ARM: dts: am4372: add minimal l4 bus layout with control module support

[Suman Anna]

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 
> ---
>  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 = ,
>;
>  
> - 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 u

Re: [PATCH 2/2] ARM: DRA7: hwmod: Fix the hwmod class for GPTimer4

[Suman Anna]

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 
> 
> 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 
> 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 
> [p...@pwsan.com: dropped dra7xx_timer_secure_hwmod_class and
>  dra7xx_timer_secure_sysc to avoid compiler warnings]
> Signed-off-by: Paul Walmsley 
> ---
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 17 +
>  1 file changed, 1 insertion(+), 16 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index d0f03e73add4..701234d8db1b 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1763,21 +1763,6 @@ static struct omap_hwmod_class 
> dra7xx_timer_1ms_hwmod_class = {
>   .sysc   = &dra7xx_timer_1ms_sysc,
>  };
>  
> -static struct omap_hwmod_class_sysconfig dra7xx_timer_secure_sysc = {
> - .rev_offs   = 0x,
> - .sysc_offs  = 0x0010,
> - .sysc_flags = (SYSC_HAS_EMUFREE | SYSC_HAS_RESET_STATUS |
> -SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
> - .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> -SIDLE_SMART_WKUP),
> - .sysc_fields= &omap_hwmod_sysc_type2,
> -};
> -
> -static struct omap_hwmod_class dra7xx_timer_secure_hwmod_class = {
> - .name   = "timer",
> - .sysc   = &dra7xx_timer_secure_sysc,
> -};
> -
>  static struct omap_hwmod_class_sysconfig dra7xx_timer_sysc = {
>   .rev_offs   = 0x,
>   .sysc_offs  = 0x0010,
> @@ -1841,7 +1826,7 @@ static struct omap_hwmod dra7xx_timer3_hwmod = {
>  /* timer4 */
>  static struct omap_hwmod dra7xx_timer4_hwmod = {
>   .name   = "timer4",
> - .class  = &dra7xx_timer_secure_hwmod_class,
> + .class  = &dra7xx_timer_hwmod_class,
>   .clkdm_name = "l4per_clkdm",
>   .main_clk   = "timer4_gfclk_mux",
>   .prcm = {
> 

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

Re: [PATCH 0/2] Couple of DRA7 hwmod patches on Timers

[Suman Anna]

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-omap&m=142661461902725&w=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

[Suman Anna]

On 03/20/2015 05:35 PM, Tony Lindgren wrote:
> * Suman Anna  [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

[Suman Anna]

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 
> ---
>  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 {
> + };
>   };

Re: [PATCH v8 0/4] hwspinlock core & omap dt support

[Suman Anna]

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

[Suman Anna]

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

[Suman Anna]

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-omap&m=142653933112526&w=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