Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tero Kristo]

On 01/04/2016 06:37 PM, Tony Lindgren wrote:

* Russell King - ARM Linux  [160104 06:43]:

On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:

On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:

FWIW, there are small loops with just a cpu_relax() in various clock drivers
under drivers/clk/shmobile/.


Just did a quick profiling round, and the clk_enable/disable delay loops
take anything from 0...1500ns, most typically consuming some 400-600ns. So,
based on this, dropping the udelay and adding cpu_relax instead looks like a
good change. I just verified that changing the udelay to cpu_relax works
fine also, I just need to change the bail-out period to be something sane.


Was that profiling done with lockdep/lock debugging enabled or disabled?


omap2plus_defconfig, so lockdep was enabled. The profiling was done 
around the while {} block though, which should not have any locks within 
it (except for the SCM clocks, which may explain some of the higher 
latency numbers seen.)



And also the thing to check from the hw folks is what all do these clkctrl
bits really control. If they group together the OCP clock and an extra
functional clock for some devices the delays could be larger.


Does it matter really? The latencies are only imposed to the device in 
question, and lets face it, the same latencies are there already with 
the hwmod implementation. This series moves the implementation under 
clock driver with as less modifications as possible to avoid any problems.



In general, I think we need to get rid of pm_runtime_irq_safe usage to
allow clocks to sleep properly. The other option is to allow toggling
pm_runtime_irq_safe but that probably gets super messy.


That is something not to be done with this set though.

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Ivaylo Dimitrov]

Hi,

On  4.01.2016 19:40, Tony Lindgren wrote:

On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:

> >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> >dmesg output?


Here it is, including the pre-gpmc log, keep in mind this is with 
restored HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get 
dmesg output from the syslog. Don't know if it is helpful :). Also, this 
device has Numonyx onenand (HW rev. 2204), unlike most of the others 
which have Samsung onenand (HW rev. 2101 etc), no idea if it is relevant.


Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Booting Linux on 
physical CPU 0x0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Initializing cgroup 
subsys cpu
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Linux version 
4.4.0-rc7+ (ivo@ivo-H81M-S2PV) (gcc version 4.7.2 20120701 (prerelease) 
(Linaro GCC 4.7-2012.07) ) #4 PREEMPT Mon Jan 4 20:30:31 EET 2016
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: ARMv7 Processor 
[411fc083] revision 3 (ARMv7), cr=10c5387d
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: PIPT / VIPT 
nonaliasing data cache, VIPT nonaliasing instruction cache

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Machine model: Nokia N900
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Memory policy: Data 
cache writeback
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] On node 0 totalpages: 
65280
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] free_area_init_node: 
node 0, pgdat c06776f8, node_mem_map cfcf9000
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 512 
pages used for memmap
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 0 pages 
reserved
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   Normal zone: 65280 
pages, LIFO batch:15
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] CPU: All CPU(s) 
started in SVC mode.
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] OMAP3430/3530 ES3.1 
(l2cache iva sgx neon isp )
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pcpu-alloc: s0 r0 
d32768 u32768 alloc=1*32768

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pcpu-alloc: [0] 0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Built 1 zonelists in 
Zone order, mobility grouping on.  Total pages: 64768
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Kernel command line: 
init=/sbin/preinit ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs 
rootflags=bulk_read,no_chk_data_crc rw mtdoops.mtddev=log console=tty0 
console=ttyO2 omapfb_vram=7M omapfb.mode=lcd:848x480-16 nokia-modem.pm=0
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] PID hash table 
entries: 1024 (order: 0, 4096 bytes)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Dentry cache hash 
table entries: 32768 (order: 5, 131072 bytes)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Inode-cache hash table 
entries: 16384 (order: 4, 65536 bytes)
Jan  4 20:42:50 Nokia-N900 cellular: csd[1026]: com.nokia.phone.SIM: 
csd-libsimpb::configure: args=<(null)>
Jan  4 20:42:50 Nokia-N900 cellular: csd[1026]: Succesfully loaded 
plugin 
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Memory: 
251588K/261120K available (4487K kernel code, 232K rwdata, 1624K rodata, 
244K init, 256K bss, 9532K reserved, 0K cma-reserved, 0K highmem)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Virtual kernel memory 
layout:
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] vector  : 
0x - 0x1000   (   4 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] fixmap  : 
0xffc0 - 0xfff0   (3072 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] vmalloc : 
0xd080 - 0xff80   ( 752 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] lowmem  : 
0xc000 - 0xd000   ( 256 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] pkmap   : 
0xbfe0 - 0xc000   (   2 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] modules : 
0xbf00 - 0xbfe0   (  14 MB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .text : 
0xc0008000 - 0xc0600044   (6113 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .init : 
0xc0601000 - 0xc063e000   ( 244 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00]   .data : 
0xc063e000 - 0xc0678240   ( 233 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00].bss : 
0xc0678240 - 0xc06b8628   ( 257 kB)
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] SLUB: HWalign=64, 
Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Preemptible 
hierarchical RCU implementation.
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] ^IBuild-time 
adjustment of leaf fanout to 32.

Jan  4 20:42:50 Nokia-N900 kernel: [0.00] NR_IRQS:16 nr_irqs:16 16
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] IRQ: Found an INTC at 
0xfa20 (revision 4.0) with 96 interrupts
Jan  4 20:42:50 Nokia-N900 kernel: [0.00] Clocking rate 
(Crystal/Core/MPU): 19.2/332/500 MHz
Jan  4 20:42:50 Nokia-N900 

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Geert Uytterhoeven]

Hi Tero,

On Mon, Jan 4, 2016 at 8:36 AM, Tero Kristo  wrote:
> On 01/01/2016 07:48 AM, Michael Turquette wrote:
>> Quoting Tero Kristo (2015-12-18 05:58:58)
>>> +static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
>>> +{
>>> +   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
>>> +   u32 val;
>>> +   int timeout = 0;
>>> +   int ret;
>>> +
>>> +   if (!clk->enable_bit)
>>> +   return 0;
>>> +
>>> +   if (clk->clkdm) {
>>> +   ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm,
>>> hw->clk);
>>> +   if (ret) {
>>> +   WARN(1,
>>> +"%s: could not enable %s's clockdomain %s:
>>> %d\n",
>>> +__func__, clk_hw_get_name(hw),
>>> +clk->clkdm_name, ret);
>>> +   return ret;
>>> +   }
>>> +   }
>>> +
>>> +   val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
>>> +
>>> +   val &= ~OMAP4_MODULEMODE_MASK;
>>> +   val |= clk->enable_bit;
>>> +
>>> +   ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
>>> +
>>> +   /* Wait until module is enabled */
>>> +   while (!_omap4_is_ready(val)) {
>>> +   udelay(1);
>>
>> This should really be a .prepare callback if you plan to keep the delays
>> in there.
>
> If this is changed to a .prepare, then all OMAP power management is
> effectively ruined as all clocks are going to be enabled all the time. hwmod
> core doesn't support .prepare/.enable at the moment that well, and changing
> that is going to be a big burden (educated guess, haven't checked this
> yet)... The call chain that comes here is:
>
> device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.
>
> The delay within this function should usually be pretty short, just to wait
> that the module comes up from idle.

Does it take multiple µs? Perhaps even one µs is much longer than needed?

> I recall the discussions regarding the udelays within clk_enable/disable
> calls, but what is the preferred approach then? Typically clk_enable/disable
> just becomes a NOP if it is not allowed to wait for hardware to complete
> transitioning before exiting the function.

FWIW, there are small loops with just a cpu_relax() in various clock drivers
under drivers/clk/shmobile/.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe 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: omapfb: Add early framebuffer memory allocator

[Tomi Valkeinen]

Hi,

On 01/01/16 14:01, Pali Rohár wrote:
> Hi Tomi! Can you review this patch? It is waiting here for two years!
> 
> On Thursday 26 December 2013 00:12:39 Ivaylo Dimitrov wrote:
>> From: Ivaylo Dimitrov 
>>
>> On memory limited devices, CMA fails easily when asked to allocate
>> big chunks of memory like framebuffer memory needed for video
>> playback.
>>
>> Add boot parameter "omapfb_memsize" which allocates memory to be used
>> as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator
>> when trying to allocate memory for the framebuffers

We probably need exactly the same for omapdrm, as omapfb is on the way
to being deprecated. And sounds to me that we probably need similar for
other devices which try to do large allocations (camera? video decoders?).

So I really think this should be somehow be a general option for any device.

I also wonder if CMA can be improved to not need anything like this? If
you just increase the CMA area, won't that increase the chances CMA will
work?

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3] irqchip: omap-intc: add support for spurious irq handling

[Sekhar Nori]

Hi Thomas,

On Tuesday 15 December 2015 08:58 PM, Tony Lindgren wrote:
> * Sekhar Nori  [151215 06:26]:
>> Under some conditions, irq sorting procedure used
>> by INTC can go wrong resulting in a spurious irq
>> getting reported.
>>
>> If this condition is not handled, it results in
>> endless stream of:
>>
>> unexpected IRQ trap at vector 00
>>
>> messages from ack_bad_irq()
>>
>> Handle the spurious interrupt condition in omap-intc
>> driver to prevent this.
>>
>> Measurements using kernel function profiler on AM335x
>> EVM running at 720MHz show that after this patch
>> omap_intc_handle_irq() takes about 37.4us against
>> 34us before this patch.
>>
>> Signed-off-by: Sekhar Nori 
> 
> Looks good to me, probably should get tagged Cc stable when
> committing:
> 
> Acked-by: Tony Lindgren 

Can you please apply this if it looks good?

Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe 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: Nokia N900 - audio TPA6130A2 problems

[Pali Rohár]

On Tuesday 04 August 2015 09:02:39 Peter Ujfalusi wrote:
> On 08/03/2015 09:48 PM, Jarkko Nikula wrote:
> > It is well possible that some regression got introduced to
> > TPA6130A2 I2C communication over the years without nobody than you
> > now notices. We used to do QA back in Meego N900 days but that was
> > pre 3.x kernels.
> 
> No major changes has been done to the tpa driver during the past
> years... I wanted to do some updates, like moving it to regmap, but
> as you said, n900 is the only user (and n9) and I do not feel
> comfortable to hack on a device where I do not have serial
> console... And I'm using the n900 time to time also.
> 
> >> So maybe something similar? Kernel expects that some PM or
> >> regulator parts are initialized, but they are only sometimes?
> >> Just speculation...
> > 
> > I'm thinking the same. I could figure SCL could be stuck low if TPA
> > or some other chip connected to the same I2C bus is without power
> > and is pulling I2C signals down.
> 
> What would happen with the SCL stuck on i2c.2 bus if you remove the
> tpa driver from the kernel? If you remove the other drivers for the
> devices on i2c.2?

Hi Peter and Jarkko! Do you have some code samples for testing? Or 
something else which I can test? This problem is still reproducible on 
more N900 devices and I would like to see it fixed.

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


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

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Michael Turquette]

Quoting Tero Kristo (2016-01-04 11:15:36)
> On 01/04/2016 06:37 PM, Tony Lindgren wrote:
> > * Russell King - ARM Linux  [160104 06:43]:
> >> On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:
> >>> On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:
>  FWIW, there are small loops with just a cpu_relax() in various clock 
>  drivers
>  under drivers/clk/shmobile/.
> >>>
> >>> Just did a quick profiling round, and the clk_enable/disable delay loops
> >>> take anything from 0...1500ns, most typically consuming some 400-600ns. 
> >>> So,
> >>> based on this, dropping the udelay and adding cpu_relax instead looks 
> >>> like a
> >>> good change. I just verified that changing the udelay to cpu_relax works
> >>> fine also, I just need to change the bail-out period to be something sane.
> >>
> >> Was that profiling done with lockdep/lock debugging enabled or disabled?
> 
> omap2plus_defconfig, so lockdep was enabled. The profiling was done 
> around the while {} block though, which should not have any locks within 
> it (except for the SCM clocks, which may explain some of the higher 
> latency numbers seen.)
> 
> > And also the thing to check from the hw folks is what all do these clkctrl
> > bits really control. If they group together the OCP clock and an extra
> > functional clock for some devices the delays could be larger.
> 
> Does it matter really? The latencies are only imposed to the device in 
> question, and lets face it, the same latencies are there already with 
> the hwmod implementation. This series moves the implementation under 
> clock driver with as less modifications as possible to avoid any problems.

So long as we can all convince ourselves that the flaw is not a flaw
then I'm OK with it. No bugs were ever introduced that way ;-)

But in fairness, we've had these delays in the .enable callbacks for a
while, so this patch does not introduce the regression. Furthermore it
does clean up some code that needs more work, and I don't want to delay
that.

I won't NACK the patch due to the delays, but it would be nice to
revisit it some day.

Regards,
Mike

> 
> > In general, I think we need to get rid of pm_runtime_irq_safe usage to
> > allow clocks to sleep properly. The other option is to allow toggling
> > pm_runtime_irq_safe but that probably gets super messy.
> 
> That is something not to be done with this set though.
> 
> -Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Re: [PATCH v11 0/4] Allow USB devices to remain runtime-suspended when sleeping

[Derek Basehore]

On Mon, Nov 02, 2015 at 02:50:40AM +0100, Rafael J. Wysocki wrote:
> 
> I've queued up this series for the second half of the v4.4 merge window.
> 
> Thanks,
> Rafael
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

What's the status of this patch series? I haven't seen the patches
posted for v4.4, plus there's the issue that Dan found that needs to be
addressed.

Is there a new revision of the patch series being worked on?
--
To unsubscribe from this list: send the line "unsubscribe 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] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov  [160104 10:59]:
> Hi,
> 
> On  4.01.2016 19:40, Tony Lindgren wrote:
> >>On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
>  >Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
>  >dmesg output?
> 
> Here it is, including the pre-gpmc log, keep in mind this is with restored
> HWMOD_INIT_NO_RESET flag so rootfs is functional and I can get dmesg output
> from the syslog. Don't know if it is helpful :). Also, this device has
> Numonyx onenand (HW rev. 2204), unlike most of the others which have Samsung
> onenand (HW rev. 2101 etc), no idea if it is relevant.

Thanks. I got the problem reproduced here too.

[1.915557] gpmc cs0 after gpmc_cs_set_timings:
[1.920410] cs0 GPMC_CS_CONFIG1: 0xfb001201

Looks like in the failing case the clock rates are not properly
calculated in GPMC and GPMCFCLKDIVIDER is set wrong in
GPMC_CS_CONFIG1. Need to look at it more to figure out what's the
best way to fix this.

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: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Michael Turquette]

Quoting Tero Kristo (2016-01-03 23:36:05)
> On 01/01/2016 07:48 AM, Michael Turquette wrote:
> > Hi Tero,
> >
> > Quoting Tero Kristo (2015-12-18 05:58:58)
> >> Previously, hwmod core has been used for controlling the hwmod level
> >> clocks. This has certain drawbacks, like being unable to share the
> >> clocks for multiple users, missing usecounting and generally being
> >> totally incompatible with common clock framework.
> >>
> >> Add support for new clock type under the TI clock driver, which will
> >> be used to convert all the existing hwmdo clocks to. This helps to
> >> get rid of the clock related hwmod data from kernel and instead
> >> parsing this from DT.
> >
> > I'm really happy to see this series. Looks pretty good to me.
> >
> >> +static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
> >> +{
> >> +   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
> >> +   u32 val;
> >> +   int timeout = 0;
> >> +   int ret;
> >> +
> >> +   if (!clk->enable_bit)
> >> +   return 0;
> >> +
> >> +   if (clk->clkdm) {
> >> +   ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm, hw->clk);
> >> +   if (ret) {
> >> +   WARN(1,
> >> +"%s: could not enable %s's clockdomain %s: 
> >> %d\n",
> >> +__func__, clk_hw_get_name(hw),
> >> +clk->clkdm_name, ret);
> >> +   return ret;
> >> +   }
> >> +   }
> >> +
> >> +   val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
> >> +
> >> +   val &= ~OMAP4_MODULEMODE_MASK;
> >> +   val |= clk->enable_bit;
> >> +
> >> +   ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
> >> +
> >> +   /* Wait until module is enabled */
> >> +   while (!_omap4_is_ready(val)) {
> >> +   udelay(1);
> >
> > This should really be a .prepare callback if you plan to keep the delays
> > in there.
> 
> If this is changed to a .prepare, then all OMAP power management is 
> effectively ruined as all clocks are going to be enabled all the time. 

Let's not ruin system PM.

> hwmod core doesn't support .prepare/.enable at the moment that well, and 
> changing that is going to be a big burden (educated guess, haven't 
> checked this yet)... The call chain that comes here is:
> 
> device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.

Right, and for calls to pm_runtime_get/put from process context it
should result in a call to clk_prepare_enable/clk_disable_unprepare. I
guess that change is hugely invasive from your statements above?

> 
> The delay within this function should usually be pretty short, just to 
> wait that the module comes up from idle.
> 
> I recall the discussions regarding the udelays within clk_enable/disable 
> calls, but what is the preferred approach then?

There are many cases where a clk only provides .{un}prepare ops and does
NOT provide any .{en,dis}able ops.

> Typically 
> clk_enable/disable just becomes a NOP

Yes, it becomes a NOP (though it is critical that drivers with knowledge
of this do not try to skip the step of calling clk_enable).

> if it is not allowed to wait for 
> hardware to complete transitioning before exiting the function.

The clk.h api clearly states that clk_prepare must be called and
complete before calling clk_enable. So if a clk only provides a .prepare
with delays but no .enable, and a consumer driver complies with that api
rule then we're guaranteed to have a toggling line when clk_enable
returns.

Regards,
Mike

> 
> -Tero
> 
> >
> > Regards,
> > Mike
> >
> 
--
To unsubscribe from this list: send the line "unsubscribe 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: omapfb: Add early framebuffer memory allocator

[Ivaylo Dimitrov]

Hi Tomi,

On  4.01.2016 13:37, Tomi Valkeinen wrote:


We probably need exactly the same for omapdrm, as omapfb is on the way
to being deprecated. And sounds to me that we probably need similar for
other devices which try to do large allocations (camera? video decoders?).



Re omapdrm - I guess it wouldn't be hard for omapdrm to use the same 
preallocated memory, when/if it is needed. Though I know nothing about 
omapdrm, so can't really tell.


If not mistaken, camera driver uses sg lists. DSP needs such a memory, 
but anyway it(driver) was removed from mainline, with no signs/hope to 
be returned anytime soon.



So I really think this should be somehow be a general option for any device.



Then maybe add the relevant people in CC, so we to start some kind of 
discussion. But until such a general option exists, I think it makes 
sense to apply the $subject patch, we can easily fix it to use whatever 
general purpose API might the discussion come up with. As it is now, 
omapfb simply cannot be used to play any video with sane resolution 
(without preallocated memory that is), unless this is the only thing the 
device does. And even then it is not assured.



I also wonder if CMA can be improved to not need anything like this? If
you just increase the CMA area, won't that increase the chances CMA will
work?



The short answer is no, at least not with the CMA code currently 
upstream. A kind of a long answer could be found on 
http://marc.info/?l=linux-mm=141571797202006=2


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

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tero Kristo]

On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:

Hi Tero,

On Mon, Jan 4, 2016 at 8:36 AM, Tero Kristo  wrote:

On 01/01/2016 07:48 AM, Michael Turquette wrote:

Quoting Tero Kristo (2015-12-18 05:58:58)

+static int _omap4_hwmod_clk_enable(struct clk_hw *hw)
+{
+   struct clk_hw_omap *clk = to_clk_hw_omap(hw);
+   u32 val;
+   int timeout = 0;
+   int ret;
+
+   if (!clk->enable_bit)
+   return 0;
+
+   if (clk->clkdm) {
+   ret = ti_clk_ll_ops->clkdm_clk_enable(clk->clkdm,
hw->clk);
+   if (ret) {
+   WARN(1,
+"%s: could not enable %s's clockdomain %s:
%d\n",
+__func__, clk_hw_get_name(hw),
+clk->clkdm_name, ret);
+   return ret;
+   }
+   }
+
+   val = ti_clk_ll_ops->clk_readl(clk->enable_reg);
+
+   val &= ~OMAP4_MODULEMODE_MASK;
+   val |= clk->enable_bit;
+
+   ti_clk_ll_ops->clk_writel(val, clk->enable_reg);
+
+   /* Wait until module is enabled */
+   while (!_omap4_is_ready(val)) {
+   udelay(1);


This should really be a .prepare callback if you plan to keep the delays
in there.


If this is changed to a .prepare, then all OMAP power management is
effectively ruined as all clocks are going to be enabled all the time. hwmod
core doesn't support .prepare/.enable at the moment that well, and changing
that is going to be a big burden (educated guess, haven't checked this
yet)... The call chain that comes here is:

device driver -> pm_runtime -> hwmod_core -> hwmod_clk_enable / disable.

The delay within this function should usually be pretty short, just to wait
that the module comes up from idle.


Does it take multiple µs? Perhaps even one µs is much longer than needed?


I recall the discussions regarding the udelays within clk_enable/disable
calls, but what is the preferred approach then? Typically clk_enable/disable
just becomes a NOP if it is not allowed to wait for hardware to complete
transitioning before exiting the function.


FWIW, there are small loops with just a cpu_relax() in various clock drivers
under drivers/clk/shmobile/.


Just did a quick profiling round, and the clk_enable/disable delay loops 
take anything from 0...1500ns, most typically consuming some 400-600ns. 
So, based on this, dropping the udelay and adding cpu_relax instead 
looks like a good change. I just verified that changing the udelay to 
cpu_relax works fine also, I just need to change the bail-out period to 
be something sane.


-Tero





Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds



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

Re: [PATCH v5 0/5] Add memory mapped read support for ti-qspi

[Vignesh R]

Hi Brian,

On 12/11/2015 09:39 AM, Vignesh R wrote:
> Changes since v4:
> Use syscon to access system control module register in ti-qspi driver.
> 

Gentle ping...
Are you ok with MTD side changes of this patch series?

> Changes since v3:
> Rework to introduce spi_flash_read_message struct.
> Support different opcode/addr/data formats as per Brian's suggestion
> here: https://lkml.org/lkml/2015/11/11/454
> 
> Changes since v2:
> Remove mmap_lock_mutex.
> Optimize enable/disable of mmap mode.
> 
> Changes since v1:
> Introduce API in SPI core that MTD flash driver can call for mmap read
> instead of directly calling spi-master driver callback. This API makes
> sure that SPI core msg queue is locked during mmap transfers.
> v1: https://lkml.org/lkml/2015/9/4/103
> 
> 
> Cover letter:
> 
> This patch series adds support for memory mapped read port of ti-qspi.
> ti-qspi has a special memory mapped port through which SPI flash
> memories can be accessed directly via SoC specific memory region.
> 
> First patch adds a method to pass flash specific information like read
> opcode, dummy bytes etc and to request mmap read. Second patch
> implements mmap read method in ti-qspi driver. Patch 3 adapts m25p80 to
> use mmap read method before trying normal SPI transfer. Patch 4 and 5
> add memory map region DT entries for DRA7xx and AM43xx SoCs.
> 
> This patch series is based on the discussions here:
> http://www.spinics.net/lists/linux-spi/msg04796.html
> 
> Tested on DRA74 EVM and AM437x-SK.
> Read performance increases from ~100kB/s to ~2.5MB/s.
> 
> Vignesh R (5):
>   spi: introduce accelerated read support for spi flash devices
>   spi: spi-ti-qspi: add mmap mode read support
>   mtd: devices: m25p80: add support for mmap read request
>   ARM: dts: DRA7: add entry for qspi mmap region
>   ARM: dts: AM4372: add entry for qspi mmap region
> 
>  Documentation/devicetree/bindings/spi/ti_qspi.txt |  22 +++-
>  arch/arm/boot/dts/am4372.dtsi |   4 +-
>  arch/arm/boot/dts/dra7.dtsi   |   6 +-
>  drivers/mtd/devices/m25p80.c  |  20 
>  drivers/spi/spi-ti-qspi.c | 139 
> +-
>  drivers/spi/spi.c |  45 +++
>  include/linux/spi/spi.h   |  41 +++
>  7 files changed, 243 insertions(+), 34 deletions(-)
> 

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

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Russell King - ARM Linux]

On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:
> On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:
> >FWIW, there are small loops with just a cpu_relax() in various clock drivers
> >under drivers/clk/shmobile/.
> 
> Just did a quick profiling round, and the clk_enable/disable delay loops
> take anything from 0...1500ns, most typically consuming some 400-600ns. So,
> based on this, dropping the udelay and adding cpu_relax instead looks like a
> good change. I just verified that changing the udelay to cpu_relax works
> fine also, I just need to change the bail-out period to be something sane.

Was that profiling done with lockdep/lock debugging enabled or disabled?

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 6/9] clk: ti: add support for omap4 module clocks

[Tony Lindgren]

* Russell King - ARM Linux  [160104 06:43]:
> On Mon, Jan 04, 2016 at 03:27:57PM +0200, Tero Kristo wrote:
> > On 01/04/2016 12:21 PM, Geert Uytterhoeven wrote:
> > >FWIW, there are small loops with just a cpu_relax() in various clock 
> > >drivers
> > >under drivers/clk/shmobile/.
> > 
> > Just did a quick profiling round, and the clk_enable/disable delay loops
> > take anything from 0...1500ns, most typically consuming some 400-600ns. So,
> > based on this, dropping the udelay and adding cpu_relax instead looks like a
> > good change. I just verified that changing the udelay to cpu_relax works
> > fine also, I just need to change the bail-out period to be something sane.
> 
> Was that profiling done with lockdep/lock debugging enabled or disabled?

And also the thing to check from the hw folks is what all do these clkctrl
bits really control. If they group together the OCP clock and an extra
functional clock for some devices the delays could be larger.

In general, I think we need to get rid of pm_runtime_irq_safe usage to
allow clocks to sleep properly. The other option is to allow toggling
pm_runtime_irq_safe but that probably gets super messy.

Regards,

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Pali Rohár  [160104 09:35]:
> On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> > Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> > dmesg output?
> 
> Hi Tony. We do not have serial console for N900 and so when kernel is 
> not fully bootable to userspace we cannot provide dmesg for you :-(

OK

> Maybe something with simple initramfs could work, but really if you have 
> serial console for N900 it should be for you lot of easier to get it.

Yeah OK will take a look ASAP. Is this happening with both legacy
booting and dts based booting?

For testing, CONFIG_INITRAMFS_SOURCE etc allow building initramfs
that's appended to the kernel.

Regards,

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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Pali Rohár]

On Monday 04 January 2016 18:02:06 Tony Lindgren wrote:
> Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related
> dmesg output?

Hi Tony. We do not have serial console for N900 and so when kernel is 
not fully bootable to userspace we cannot provide dmesg for you :-(

Maybe something with simple initramfs could work, but really if you have 
serial console for N900 it should be for you lot of easier to get it.

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


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

Re: Nokia N900: twl4030-power different data in DTS and board code

[Tony Lindgren]

* Pali Rohár  [160102 13:39]:
> On Saturday 02 January 2016 18:14:31 Tony Lindgren wrote:
> 
> > The n900 specific code was based on something before the TI generic
> > values were available I think. And the last time I looked at it I
> > came to the conclusion the n900 specific code is no better.
> 
> Hm... if generic values are better, why old values are still there (in 
> board n900 code)?

We never had PM working in a generic way for the legacy booting but
relied on board specific configuration instead for the ones that did
work. Probably not worth changing the board-*.c file configuration
unless you want to test that the new generic settings work.

> > Or did I miss something? Are you seeing some issues with PM with dts
> > based code?
> 
> I'm just asking why we have different code for DST and board...

OK. Yeah no reason beyond somebody taking the time to verify that the
generic settings work on n900 in legacy booting mode :)

> > We can certainly add it to twl4030-power if it provides something
> > that the "ti,twl4030-power-idle-osc-off" does not.
> 
> But do we need 'compatible = "ti,twl4030-power-n900"' specification in 
> omap3-n900.dts file at all?

Well that generally done to allow adding support for the board specific
configuration if needed with a fallback to the generic configuration.
That's used quite a bit, for example boards typically set the compatible
to the specific board but still end up booting with a generic one
sucha as "ti,omap3".

Regards,

Tony


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

Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug

[Tony Lindgren]

* Ivaylo Dimitrov  [160101 03:29]:
> Hi Tony,
> 
> On 21.05.2015 00:21, Tony Lindgren wrote:
> >We support decoding the bootloader values if DEBUG is defined.
> >But we also need to change the struct omap_hwmod flags to have
> >HWMOD_INIT_NO_RESET to avoid the GPMC being reset during the
> >boot. Otherwise just the default timings will be displayed
> >instead of the bootloader configured timings.
> >
> >This also allows us to clean up the various GPMC related
> >hwmod flags. For debugging, we only need HWMOD_INIT_NO_RESET,
> >and HWMOD_INIT_NO_IDLE is not needed.
> >
> >Cc: Brian Hutchinson 
> >Cc: Paul Walmsley 
> >Cc: Roger Quadros 
> >Signed-off-by: Tony Lindgren 
> >---
> >  arch/arm/mach-omap2/omap_hwmod.h|  6 ++
> >  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c  | 12 ++--
> >  arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c |  3 ++-
> >  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c  | 12 ++--
> >  arch/arm/mach-omap2/omap_hwmod_44xx_data.c  | 11 ++-
> >  arch/arm/mach-omap2/omap_hwmod_7xx_data.c   |  4 ++--
> >  arch/arm/mach-omap2/omap_hwmod_81xx_data.c  |  2 ++
> >  drivers/memory/Kconfig  |  8 
> >  drivers/memory/omap-gpmc.c  |  6 +++---
> >  9 files changed, 29 insertions(+), 35 deletions(-)
> >
> 
> 1. Happy new year :)

Same to you :)

> 2. It was a while I tested upstream on N900 but I had some spare time during
> the holidays to play, so I tried to boot 4.4-rc6 with Maemo 5. To my
> surprise, after that try, Maemo 5 rootfs, which is located on onenand became
> irreversibly corrupted. I bisected the tree to the $subject commit and after
> restoring HWMOD_INIT_NO_RESET in omap3xxx_gpmc_hwmod flags, the problem was
> solved. It seems that GPMC is either incorrectly or incompletely setup by
> the kernel, leading to failed onenand reads/writes and whatnot.
> Unfortunately, what I have here is a release device, so I am unable to
> capture any logs through the serial port. BTW keep in mind that rootfs
> corruption happens as soon as a boot is attempted, even after a freshly
> flashed rootfs.

Oh crap, sorry to hear that :(

Care to boot with CONFIG_OMAP_GPMC_DEBUG=y and post the gpmc related dmesg
output? The dmesg timings with CONFIG_OMAP_GPMC_DEBUG enabled should be
compared against omap3-n900.dts gpmc timings. And if you don't see the whole
dmesg after booting, you may need to also increase CONFIG_LOG_BUF_SHIFT.
Meanwhile, I'll try to also produce it here.

Chances are we have bad or incomplete timings in the n900 :(

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