Re: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
an 6 10:34:16 Nokia-N900 kernel: [2.683685] gpmc,burst-length = <4> > Jan 6 10:34:16 Nokia-N900 kernel: [2.687408] gpmc cs1 timings > configuration: > Jan 6 10:34:16 Nokia-N900 kernel: [2.691833] gpmc,cs-on-ns = <0> /* 0 > ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.697692] gpmc,cs-rd-off-ns = <48> > /* 43 ns - 48 ns; 8 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.704132] gpmc,cs-wr-off-ns = <24> > /* 19 ns - 24 ns; 4 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.710601] gpmc,adv-on-ns = <0> /* 0 > ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.716552] gpmc,adv-rd-off-ns = <0> > /* 0 ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.722808] gpmc,adv-wr-off-ns = <0> > /* 0 ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.729125] gpmc,oe-on-ns = <12> /* 7 > ns - 12 ns; 2 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.735137] gpmc,oe-off-ns = <48> /* > 43 ns - 48 ns; 8 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.741333] gpmc,we-on-ns = <12> /* 7 > ns - 12 ns; 2 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.747375] gpmc,we-off-ns = <18> /* > 13 ns - 18 ns; 3 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.753509] gpmc,rd-cycle-ns = <180> > /* 175 ns - 180 ns; 30 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.760284] gpmc,wr-cycle-ns = <180> > /* 175 ns - 180 ns; 30 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.767059] gpmc,access-ns = <42> /* > 37 ns - 42 ns; 7 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.773254] gpmc,page-burst-access-ns > = <0> /* 0 ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.780212] gpmc,bus-turnaround-ns = > <0> /* 0 ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.786895] gpmc,cycle2cycle-delay-ns > = <0> /* 0 ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.793853] gpmc,wait-monitoring-ns = > <0> /* 0 ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.800628] gpmc,clk-activation-ns = > <0> /* 0 ns - 0 ns; 0 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.807312] gpmc,wr-data-mux-bus-ns = > <12> /* 7 ns - 12 ns; 2 ticks */ > Jan 6 10:34:16 Nokia-N900 kernel: [2.814270] gpmc,wr-access-ns = <0> /* > 0 ns - 0 ns; 0 ticks */ Just one note. In future, please do not send logs in format flowed emails as space on end of line has special meanings. And output is wrapped randomly and hard to read (like in my quoted text above). If you are unable to configure email client correctly (turn of format flowed) then rather attach logs as attachment (ideally marked with Content-Disposition: inline). See linux/Documentation/email-clients.txt where are very useful hints how to fix buggy email clients. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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: Broken lirc ir-rx51 driver
On Saturday 02 January 2016 09:06:57 Tony Lindgren wrote: > Hi, > > * Pali Rohár <pali.ro...@gmail.com> [160102 06:46]: > > --- a/drivers/media/rc/ir-rx51.c > > +++ b/drivers/media/rc/ir-rx51.c > > @@ -25,9 +25,9 @@ > > #include > > #include > > #include > > +#include > > > > -#include > > -#include > > +#include "../../../arch/arm/plat-omap/include/plat/dmtimer.h" > > Well we don't want to export the dmtimer functions to drivers..But > we now have the PWM driver that can be already used for most of the > ir-rx51.c. Ok. Is PWM driver included in mainline kernel? > > #include > > #include > > @@ -208,7 +208,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 > > *lirc_rx51) > > } > > > > clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer); > > - lirc_rx51->fclk_khz = clk_fclk->rate / 1000; > > + lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000; > > > > return 0; > > > > > > So Tony, you are author of that commit (a62a6e98c3) which broke ir-rx51 > > module for Nokia N900. Do you know how to fix this driver for upstream > > kernel? It would be great to have driver working and not to have it in > > this dead state... > > Yup please take a look at thread "[PATCH 0/3] pwm: omap: Add PWM support > using dual-mode timers". Chances are we still need to set up the dmtimer > code to provide also irqchip functions. That way ir-rx51.c can just do > request_irq on the selected dmtimer for interrupts. No I see that patch from that thread uses dmtimer.h from plat-omap. So it is really OK? > > Also platform data for this driver are only in legacy board code. > > Support in DTS is missing, so driver (after fixing above problem) cannot > > be used on DT booted kernel. > > Yeah those parts should be already doable with the PWM timer code AFAIK. > > Regards, > > Tony > > -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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: Adjust MPU OPP values
On Saturday 02 January 2016 14:38:36 Nishanth Menon wrote: > On 01/02/2016 11:16 AM, Tony Lindgren wrote: > > * Pali Rohár <pali.ro...@gmail.com> [160102 06:31]: > >> Hello, > >> > >> MPU OPP table table (omap36xx_vddcore_volt_data) defined in > >> opp3xxx_data.c does not match Nokia N900 phone. For a long time we have > >> dirty patch in linux-n900 tree for it, see: > >> > >> https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c > >> > >> Now when doing transition to device tree, is there any way how correct > >> MPU OOP table for Nokia N900 could be defined in DT file? > > > > Hmm I'd assume we can just define this in the dts.. Nishanth, got > > any comments on this one? > > > > We already have definitions in dtb for omap3 OPPs. I think we should > start using device tree as default. the oppxx_data.c is sticking around > waiting for legacy boot to go away, then those files should be deleted. > Freemangordon, maybe... would it be possible to add (now stable and tested by lot of users) OPP table from Maemo kernel-power to DTS? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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
On Monday 04 January 2016 20:13:56 Tony Lindgren wrote: > * Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com> [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 Hm... Maybe this problem is in U-Boot too? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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: dts: omap3: Include missing bandgap data for ti-soc-thermal driver
On Thursday 31 December 2015 09:38:45 Eduardo Valentin wrote:
> > +
> > + bandgap {
> > + reg = <0x48002524 0x4>;
> > + compatible = "ti,omap36xx-bandgap";
>
> Can you please already add on both cases
>
> #thermal-sensor-cells = <0>;
> ?
>
> This way we can already use them to define thermal zones. Of course,
> that alone won't add the thermal zones. A separated patch would be
> needed to add the thermal zone for OMAP3.
Are you going to add thermal zone defines? If yes, then it would make
sense to add that #thermal line together with thermal zone defines...
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"
On Monday 28 December 2015 23:27:17 Arnd Bergmann wrote: > On Monday 28 December 2015 13:01:22 Frank Rowand wrote: > > > > Patch 2/5 copies the value from ATAG_REVISION into the fdt "/revision" > > property. > > > > If the use of /revision is limited to being a location to hold an ATAG > > value to pass to the global variable system_rev, then it would make > > sense to just copy directly from the ATAG value into system_rev in the > > same board file where you are copying the ATAGs. > > Agreed. That would be simpler, and avoid a situation where someone relies > on the /revision property in DT to be set from the atags compat code > (preventing an upgrade to a newer bootloader), or on the system_rev variable > to be the same across multiple boot loaders, in the absence of other > kernel code setting it. So, set system_rev only for Nokia N900? At same place where is called save_atags()? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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
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: [PATCH 2/2] memory: omap-gpmc: Add Kconfig option for debug
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.
Nokia N900: twl4030-power different data in DTS and board code
Hello, now I'm looking at differences between legacy board code and DTS file for Nokia N900 and I see some inconsistency for twl4030-power driver. In board code are defined more twl4030 power scripts which override defaults defined in twl4030-power code. See: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mach-omap2/board-rx51-peripherals.c#n790 Next in DTS file is defined just "compatible" keyword, but no custom scripts, see: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/omap3-n900.dts#n416 And the last in DTS file is defined line: compatible = "ti,twl4030-power-n900" which is not in twl4030-power driver itself, see: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/mfd/twl4030-power.c#n851 So all this stuff looks like some errors when board code was ported to DTS. Tony, can you look at this at all? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Nokia N900: Adjust MPU OPP values
Hello, MPU OPP table table (omap36xx_vddcore_volt_data) defined in opp3xxx_data.c does not match Nokia N900 phone. For a long time we have dirty patch in linux-n900 tree for it, see: https://github.com/pali/linux-n900/commit/4644c5801d7469e2be01d847c61df3d934dadd8c Now when doing transition to device tree, is there any way how correct MPU OOP table for Nokia N900 could be defined in DT file? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Nokia N900: Broken lirc ir-rx51 driver
Hello, due to this commit (ARM: OMAP2+: Disable code that currently does not work with multiplaform) https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/media/rc/Kconfig?id=a62a6e98c370ccca37d353a5f763b532411a4c14 lirc driver for Nokia N900 (ir-rx51) cannot be enabled via make menuconfig. It is because Nokia N900 support cannot be compiled without ARCH_MULTIPLATFORM, but Nokia N900 lirc driver (IR_RX51) cannot be compiled when ARCH_MULTIPLATFORM is enabled. Because ir-rx51 driver is just for Nokia N900 it is nonsense to have such condition because nobody can use ir-rx51 driver... It is even not possible to enable compilation for it... Here is simple patch which enable compilation for Nokia N900 and fix compile errors: diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index b6e1311..f70d4c7 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -335,7 +335,7 @@ config IR_TTUSBIR config IR_RX51 tristate "Nokia N900 IR transmitter diode" - depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC && !ARCH_MULTIPLATFORM + depends on OMAP_DM_TIMER && ARCH_OMAP2PLUS && LIRC ---help--- Say Y or M here if you want to enable support for the IR transmitter diode built in the Nokia N900 (RX51) device. diff --git a/drivers/media/rc/ir-rx51.c b/drivers/media/rc/ir-rx51.c index b1e19a2..be29bd0 100644 --- a/drivers/media/rc/ir-rx51.c +++ b/drivers/media/rc/ir-rx51.c @@ -25,9 +25,9 @@ #include #include #include +#include -#include -#include +#include "../../../arch/arm/plat-omap/include/plat/dmtimer.h" #include #include @@ -208,7 +208,7 @@ static int lirc_rx51_init_port(struct lirc_rx51 *lirc_rx51) } clk_fclk = omap_dm_timer_get_fclk(lirc_rx51->pwm_timer); - lirc_rx51->fclk_khz = clk_fclk->rate / 1000; + lirc_rx51->fclk_khz = clk_get_rate(clk_fclk) / 1000; return 0; So Tony, you are author of that commit (a62a6e98c3) which broke ir-rx51 module for Nokia N900. Do you know how to fix this driver for upstream kernel? It would be great to have driver working and not to have it in this dead state... Also platform data for this driver are only in legacy board code. Support in DTS is missing, so driver (after fixing above problem) cannot be used on DT booted kernel. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Nokia N900: Proper C-states
Hello, due to this Daniel Lezcano commit (ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table) https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=231900afba52d6faddfb480cde4132d4edc089bc we need patch cpuidle34xx.c code to fix commit for Nokia N900. See: https://github.com/pali/linux-n900/commit/e147fd4b678f1f3d7a5235287910960bd41e04dc As Nokia N900 code is converting from legacy board code to DST, I would like to know how to patch correctly omap3_idle_driver in DTS with correct values measured for Nokia N900. Thanks! -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote: > On Monday 28 December 2015 15:54:35 Pali Rohár wrote: > > On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote: > > > On Monday 28 December 2015 15:28:48 Pali Rohár wrote: > > > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > > > > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > > > > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > > > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > > > > > > * Arnd Bergmann <a...@arndb.de> [150515 14:26]: > > > > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > > > > > > > If setting up the generic binding is expected to take a > > > > > > > > while, you can naturally pass it in pdata while waiting > > > > > > > > for the generic binding to get merged. > > > > > > > > > > > > > > Yes, good idea. So the n900 machine can use auxdata to > > > > > > > pass this for the time being, while the binding and > > > > > > > generic implementation is being worked out. > > > > > > > > > > > > Ok, so what is needed to finish this patch series? > > > > > > > > > > I don't know where we are at this point. Has either the > > > > > auxdata approach or the generic binding been worked on at > > > > > all? > > > > > > > > What are auxdata data? > > > > > > I mean you can add the platform data to the omap_auxdata_lookup[] > > > table for this board. > > > > But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]? > > Yes. > > Arnd Hm... looks like it is not possible. omap_hsmmc driver ignores any supplied platform data if there are device tree data. So array omap_auxdata_lookup[] does not help. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Saturday 02 January 2016 23:57:47 Arnd Bergmann wrote:
> On Saturday 02 January 2016 16:22:03 Pali Rohár wrote:
> > On Monday 28 December 2015 15:55:28 Arnd Bergmann wrote:
> > > On Monday 28 December 2015 15:54:35 Pali Rohár wrote:
> > > > > I mean you can add the platform data to the
> > > > > omap_auxdata_lookup[] table for this board.
> > > >
> > > > But can I mix data from omap3-n900.dts and
> > > > omap_auxdata_lookup[]?
> >
> > Hm... looks like it is not possible. omap_hsmmc driver ignores any
> > supplied platform data if there are device tree data. So array
> > omap_auxdata_lookup[] does not help.
>
> Obviously you need to the driver to work with that setting. Maybe
> something as simple as
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c
> b/drivers/mmc/host/omap_hsmmc.c index e06b1881b6a1..4fa35fc84b8b
> 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2006,7 +2006,7 @@ static int omap_hsmmc_probe(struct
> platform_device *pdev) void __iomem *base;
>
> match = of_match_device(of_match_ptr(omap_mmc_of_match),
> >dev); -if (match) {
> + if (!pdata && match) {
> pdata = of_get_hsmmc_pdata(>dev);
>
> if (IS_ERR(pdata))
>
>
> Arnd
But in this case I must copy mmc definition from omap3-n900.dts file
back to board code to omap_auxdata_lookup[]. And mmc definitions in
omap3-n900.dts will be ignored. This is step back.
Mixing mmc definitions from DTS file together with omap_auxdata_lookup[]
just will not work.
--
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
On Saturday 02 January 2016 18:14:31 Tony Lindgren wrote: > * Pali Rohár <pali.ro...@gmail.com> [160102 06:14]: > > Hello, > > > > now I'm looking at differences between legacy board code and DTS > > file for Nokia N900 and I see some inconsistency for twl4030-power > > driver. > > > > In board code are defined more twl4030 power scripts which override > > defaults defined in twl4030-power code. See: > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre > > e/arch/arm/mach-omap2/board-rx51-peripherals.c#n790 > > > > Next in DTS file is defined just "compatible" keyword, but no > > custom scripts, see: > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre > > e/arch/arm/boot/dts/omap3-n900.dts#n416 > > > > And the last in DTS file is defined line: > > > > compatible = "ti,twl4030-power-n900" > > > > which is not in twl4030-power driver itself, see: > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tre > > e/drivers/mfd/twl4030-power.c#n851 > > > > So all this stuff looks like some errors when board code was ported > > to DTS. Tony, can you look at this at all? > > AFAIK it should work fine with the generic > "ti,twl4030-power-idle-osc-off". This means reboot works and > regulators are cut off during off mode. Ok. > 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)? > 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... > 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? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator
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 <freemangor...@abv.bg>
>
> 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
>
> Signed-off-by: Ivaylo Dimitrov <freemangor...@abv.bg>
> ---
> arch/arm/mach-omap2/common.c |1 +
> arch/arm/mach-omap2/common.h |2 +
> arch/arm/mach-omap2/fb.c | 46
> +- 3 files changed, 48
> insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/common.c
> b/arch/arm/mach-omap2/common.c index 2dabb9e..9beecde 100644
> --- a/arch/arm/mach-omap2/common.c
> +++ b/arch/arm/mach-omap2/common.c
> @@ -33,4 +33,5 @@ void __init omap_reserve(void)
> omap_dsp_reserve_sdram_memblock();
> omap_secure_ram_reserve_memblock();
> omap_barrier_reserve_memblock();
> + omap_fb_reserve_memblock();
> }
> diff --git a/arch/arm/mach-omap2/common.h
> b/arch/arm/mach-omap2/common.h index e30ef67..21afdc0 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -304,6 +304,8 @@ extern void omap_reserve(void);
> struct omap_hwmod;
> extern int omap_dss_reset(struct omap_hwmod *);
>
> +extern void omap_fb_reserve_memblock(void);
> +
> /* SoC specific clock initializer */
> extern int (*omap_clk_init)(void);
>
> diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
> index 26e28e9..0eacbe9 100644
> --- a/arch/arm/mach-omap2/fb.c
> +++ b/arch/arm/mach-omap2/fb.c
> @@ -30,6 +30,7 @@
> #include
>
> #include
> +#include
>
> #include "soc.h"
> #include "display.h"
> @@ -106,10 +107,53 @@ static struct platform_device omap_fb_device =
> { .num_resources = 0,
> };
>
> +static phys_addr_t omapfb_mem_base __initdata;
> +static phys_addr_t omapfb_mem_size __initdata;
> +
> +void __init omap_fb_reserve_memblock(void)
> +{
> + if (omapfb_mem_size) {
> + omapfb_mem_base = arm_memblock_steal(omapfb_mem_size, SZ_1M);
> + if (omapfb_mem_base)
> + pr_info("omapfb: reserved %u bytes at %x\n",
> + omapfb_mem_size, omapfb_mem_base);
> + else
> + pr_err("omapfb: arm_memblock_steal failed\n");
> + }
> +}
> +
> int __init omap_init_fb(void)
> {
> - return platform_device_register(_fb_device);
> + int ret;
> +
> + ret = platform_device_register(_fb_device);
> +
> + if (ret)
> + return ret;
> +
> + if (!omapfb_mem_base)
> + return 0;
> +
> + ret = dma_declare_coherent_memory(_fb_device.dev,
> + omapfb_mem_base, omapfb_mem_base,
> + omapfb_mem_size, DMA_MEMORY_MAP |
> + DMA_MEMORY_EXCLUSIVE);
> + if (!(ret & DMA_MEMORY_MAP))
> + pr_err("omapfb: dma_declare_coherent_memory failed\n");
> +
> + return 0;
> +}
> +
> +static int __init early_omapfb_memsize(char *p)
> +{
> + omapfb_mem_size = ALIGN(memparse(p, ), SZ_1M);
> +
> + if(!omapfb_mem_size)
> + pr_err("omapfb: bad memsize parameter\n");
> +
> + return 0;
> }
> +early_param("omapfb_memsize", early_omapfb_memsize);
> #else
> int __init omap_init_fb(void) { return 0; }
> #endif
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > > * Arnd Bergmann <a...@arndb.de> [150515 14:26]: > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > > > If setting up the generic binding is expected to take a while, > > > > you can naturally pass it in pdata while waiting for the > > > > generic binding to get merged. > > > > > > Yes, good idea. So the n900 machine can use auxdata to pass this > > > for the time being, while the binding and generic implementation > > > is being worked out. > > > > Ok, so what is needed to finish this patch series? > > I don't know where we are at this point. Has either the auxdata > approach or the generic binding been worked on at all? What are auxdata data? And what do you mean with "generic binding" approach? > If not, please try to get the auxdata variant to work, it should not > be hard at all because there is no dependency on a generic binding. > > Arnd -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 28 December 2015 15:41:01 Arnd Bergmann wrote: > On Monday 28 December 2015 15:28:48 Pali Rohár wrote: > > On Monday 28 December 2015 15:14:50 Arnd Bergmann wrote: > > > On Friday 25 December 2015 13:53:11 Pali Rohár wrote: > > > > On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > > > > > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > > > > > * Arnd Bergmann <a...@arndb.de> [150515 14:26]: > > > > > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > > > > > If setting up the generic binding is expected to take a > > > > > > while, you can naturally pass it in pdata while waiting > > > > > > for the generic binding to get merged. > > > > > > > > > > Yes, good idea. So the n900 machine can use auxdata to pass > > > > > this for the time being, while the binding and generic > > > > > implementation is being worked out. > > > > > > > > Ok, so what is needed to finish this patch series? > > > > > > I don't know where we are at this point. Has either the auxdata > > > approach or the generic binding been worked on at all? > > > > What are auxdata data? > > I mean you can add the platform data to the omap_auxdata_lookup[] > table for this board. But can I mix data from omap3-n900.dts and omap_auxdata_lookup[]? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/2] mmc: omap_hsmmc: Add support for slot-name property in DT
On Monday 18 May 2015 17:07:57 Arnd Bergmann wrote: > On Monday 18 May 2015 08:06:07 Tony Lindgren wrote: > > * Arnd Bergmann <a...@arndb.de> [150515 14:26]: > > > On Friday 15 May 2015 23:22:37 Pali Rohár wrote: > > If setting up the generic binding is expected to take a while, > > you can naturally pass it in pdata while waiting for the generic > > binding to get merged. > > Yes, good idea. So the n900 machine can use auxdata to pass this for > the time being, while the binding and generic implementation is > being worked out. > > Arnd Ok, so what is needed to finish this patch series? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH] ARM: dts: n900: Include adp1653 device
This patch adds adp1653 device into n900 DT structure. DT support in
adp1653 driver is there since v4.2-rc1 version.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
arch/arm/boot/dts/omap3-n900.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 5f5e0f3..ba93642 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -522,6 +522,21 @@
amstaos,cover-comp-gain = <16>;
};
+ adp1653: led-controller@30 {
+ compatible = "adi,adp1653";
+ reg = <0x30>;
+ enable-gpios = < 24 GPIO_ACTIVE_HIGH>; /* 88 */
+
+ flash {
+ flash-timeout-us = <50>;
+ flash-max-microamp = <32>;
+ led-max-microamp = <5>;
+ };
+ indicator {
+ led-max-microamp = <17500>;
+ };
+ };
+
lp5523: lp5523@32 {
compatible = "national,lp5523";
reg = <0x32>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: omap3: Include missing bandgap data for ti-soc-thermal driver
Driver for omap3 with documentation is there since v4.4-rc1.
Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
---
arch/arm/boot/dts/omap34xx.dtsi |5 +
arch/arm/boot/dts/omap36xx.dtsi |5 +
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 4f6b2d5..c3f488f 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -54,6 +54,11 @@
#size-cells = <0>;
};
};
+
+ bandgap {
+ reg = <0x48002524 0x4>;
+ compatible = "ti,omap34xx-bandgap";
+ };
};
};
diff --git a/arch/arm/boot/dts/omap36xx.dtsi b/arch/arm/boot/dts/omap36xx.dtsi
index 86253de..00f98c1 100644
--- a/arch/arm/boot/dts/omap36xx.dtsi
+++ b/arch/arm/boot/dts/omap36xx.dtsi
@@ -86,6 +86,11 @@
#size-cells = <0>;
};
};
+
+ bandgap {
+ reg = <0x48002524 0x4>;
+ compatible = "ti,omap36xx-bandgap";
+ };
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] arm: devtree: Set system_rev from DT "/revision"
On Monday 06 July 2015 22:26:09 Pali Rohár wrote:
> With this patch "/revision" DT entry is used to set global system_rev
> variable. DT "/revision" is expected to be u32 numeric value.
>
> TODO: add documentation
>
> Signed-off-by: Pali Rohár <pali.ro...@gmail.com>
> ---
> arch/arm/kernel/devtree.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..7d82749 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -26,6 +27,7 @@
> #include
> #include
> #include
> +#include
>
>
> #ifdef CONFIG_SMP
> @@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char
> *const **match)
> const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
> {
> const struct machine_desc *mdesc, *mdesc_best = NULL;
> + unsigned long dt_root;
> + const u32 *rev;
>
> #ifdef CONFIG_ARCH_MULTIPLATFORM
> DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -215,17 +219,16 @@ const struct machine_desc * __init
> setup_machine_fdt(unsigned int dt_phys)
> if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
> return NULL;
>
> + dt_root = of_get_flat_dt_root();
> mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
>
> if (!mdesc) {
> const char *prop;
> int size;
> - unsigned long dt_root;
>
> early_print("\nError: unrecognized/unsupported "
> "device tree compatible list:\n[ ");
>
> - dt_root = of_get_flat_dt_root();
> prop = of_get_flat_dt_prop(dt_root, "compatible", );
> while (size > 0) {
> early_print("'%s' ", prop);
> @@ -246,5 +249,10 @@ const struct machine_desc * __init
> setup_machine_fdt(unsigned int dt_phys)
> /* Change machine number to match the mdesc we're using */
> __machine_arch_type = mdesc->nr;
>
> + /* Set system revision from DT */
> + rev = of_get_flat_dt_prop(dt_root, "revision", NULL);
> + if (rev)
> + system_rev = fdt32_to_cpu(*rev);
> +
> return mdesc;
> }
This patch and second one (with subject "[PATCH 2/5] arm: boot: convert
ATAG_REVISION to DT "/revision" entry") are still needed.
Are there any objections for them? If not, I will add missing DT
documentation and will resend them.
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe 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: ATAGS: move save_atags() to include/asm arch/arm/include/asm/setup.h
On Thursday 24 December 2015 17:37:55 Ivaylo Dimitrov wrote: > So it can be used by code outside arch/arm/kernel/. Fix save_atags() > declaration to match its definition while at it. > > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com> Tested-by: Pali Rohár <pali.ro...@gmail.com> -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/2] OMAP: RX51: save ATAGS data in the early boot stage
On Thursday 24 December 2015 17:37:56 Ivaylo Dimitrov wrote: > Nokia N900 (RX51) legacy userspace needs various ATAGS passed by the > bootloader (boot reason, device serial, boot mode, various GPIO > swithes, etc). Save that data early enough in the boot process, so > it can be exported later in /proc/atags > > Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov...@gmail.com> Working fine in qemu. Tested-by: Pali Rohár <pali.ro...@gmail.com> -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Monday 30 November 2015 11:09:42 Nicolas Pitre wrote: > On Mon, 30 Nov 2015, Pali Rohár wrote: > > > On Monday 30 November 2015 07:23:53 Tony Lindgren wrote: > > > * Pali Rohár <pali.ro...@gmail.com> [151129 16:16]: > > > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote: > > > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote: > > > > > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote: > > > > > > > Good. And Arnd likes the idea too. So we might be converging at > > > > > > > last which is a good thing. > > > > > > > > > > > > I disagree with the idea that there is convergence. There might be > > > > > > convergence towards an idea, but... Here's a mail extract, from > > > > > > July 7th, from earlier in this very thread: > > > > > > > > > > > > Pali: > > > > > > > Me: > > > > > > > > Are the ATAGs at a fixed address on the N900? > > > > > > > > > > > > > > Yes, in board-rx51.c is: > > > > > > > > > > > > > > .atag_offset= 0x100 > > > > > > > > > > > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > > > > > > > > > > > Can that be handled in > > > > > > > > some kind of legacy file for the N900 which calls save_atags() > > > > > > > > on it, so we don't end up introducing yet more stuff that we > > > > > > > > have to maintain into the distant future? If not, what about > > > > > > > > copying a known working atag structure into a legacy file for > > > > > > > > the N900? > > > > > > > > > > > > > > I already asked question if it is possible to read ATAGs from DT > > > > > > > booted kernel. And somebody (do not remember who) wrote to ML, > > > > > > > that it is not possible and it can be done in that uncompress > > > > > > > code. > > > > > > > > > > Who is that somebody? If ever it happened to be me then objection is > > > > > withdrawn. Otherwise that somebody should come forth and speak up > > > > > again. > > > > > > > > > > > > > ... do not remember ... this discussion were in more email threads and > > > > takes more then one year... sorry but my memory is not excellent > > > > > > Yes this certainly seems like the best solution. I think we got into > > > the atags-to-dt track as some of the atags are already being translated. > > > > > > In this case there's no need to translate them AFAIK. You can just > > > parse them and have them available for the user space. So as long as > > > nothing trashes the atags at the atag_offset, you should be able to > > > call a function to parse them in the n900 specific init_machine. > > > > > > Regards, > > > > > > Tony > > > > In arch/arm/kernel/setup.c is function setup_arch() and it calls: > > > > mdesc = setup_machine_fdt(__atags_pointer); > > if (!mdesc) > > mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type); > > > > So it looks like that on atags address is stored either atags structure > > or DT structure... so it is truth kernel uncompress code put DT blob to > > same offset where is expected atags structure? > > No. It doesn't put it anywhere. Those functions read DT/ATAGs from the > passed address. But you know this address won't be the one you want for > the legacy ATAGs. > > What you should do is to add a init_early hook to your mdesc structure > and retrieve your ATAGs from there directly at PAGE_OFFSET + 0x100. > > Now I suspect paging_init() marks the point where the ATAGs will be > overwritten. To prevent this, you might have to add an additional tweak > in arm_mm_memblock_reserve() similar to the one already present for > CONFIG_SA. Something like: > > memblock_reserve(PHYS_OFFSET, PAGE_SIZE); > > And later on you can return that page back to the system. > > > Nicolas So am I understand correctly that solution would be to hack arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET? And should be this just when when we detect Nokia N900 in DT? Or for all OMAP2 boards? Or all ARM boards? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Monday 30 November 2015 07:23:53 Tony Lindgren wrote: > * Pali Rohár <pali.ro...@gmail.com> [151129 16:16]: > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote: > > > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote: > > > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote: > > > > > Good. And Arnd likes the idea too. So we might be converging at > > > > > last which is a good thing. > > > > > > > > I disagree with the idea that there is convergence. There might be > > > > convergence towards an idea, but... Here's a mail extract, from > > > > July 7th, from earlier in this very thread: > > > > > > > > Pali: > > > > > Me: > > > > > > Are the ATAGs at a fixed address on the N900? > > > > > > > > > > Yes, in board-rx51.c is: > > > > > > > > > > .atag_offset= 0x100 > > > > > > > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > > > > > > > Can that be handled in > > > > > > some kind of legacy file for the N900 which calls save_atags() > > > > > > on it, so we don't end up introducing yet more stuff that we > > > > > > have to maintain into the distant future? If not, what about > > > > > > copying a known working atag structure into a legacy file for > > > > > > the N900? > > > > > > > > > > I already asked question if it is possible to read ATAGs from DT > > > > > booted kernel. And somebody (do not remember who) wrote to ML, > > > > > that it is not possible and it can be done in that uncompress > > > > > code. > > > > > > Who is that somebody? If ever it happened to be me then objection is > > > withdrawn. Otherwise that somebody should come forth and speak up > > > again. > > > > > > > ... do not remember ... this discussion were in more email threads and > > takes more then one year... sorry but my memory is not excellent > > Yes this certainly seems like the best solution. I think we got into > the atags-to-dt track as some of the atags are already being translated. > > In this case there's no need to translate them AFAIK. You can just > parse them and have them available for the user space. So as long as > nothing trashes the atags at the atag_offset, you should be able to > call a function to parse them in the n900 specific init_machine. > > Regards, > > Tony In arch/arm/kernel/setup.c is function setup_arch() and it calls: mdesc = setup_machine_fdt(__atags_pointer); if (!mdesc) mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type); So it looks like that on atags address is stored either atags structure or DT structure... so it is truth kernel uncompress code put DT blob to same offset where is expected atags structure? If yes, then this is probably reason why atags cannot be read from booted DT kernel. Can somebody with deep knowledge of DT/atags and uncompress code verify this? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Sunday 29 November 2015 19:09:39 Russell King - ARM Linux wrote: > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote: > > Good. And Arnd likes the idea too. So we might be converging at > > last which is a good thing. > > I disagree with the idea that there is convergence. There might be > convergence towards an idea, but... Here's a mail extract, from July > 7th, from earlier in this very thread: > > Pali: > > Me: > > > Are the ATAGs at a fixed address on the N900? > > > > Yes, in board-rx51.c is: > > > > .atag_offset= 0x100 > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > Can that be handled in > > > some kind of legacy file for the N900 which calls save_atags() on > > > it, so we don't end up introducing yet more stuff that we have > > > to maintain into the distant future? If not, what about copying > > > a known working atag structure into a legacy file for the N900? > > > > I already asked question if it is possible to read ATAGs from DT > > booted kernel. And somebody (do not remember who) wrote to ML, > > that it is not possible and it can be done in that uncompress > > code. > > So you're converging on an idea that has already been rejected. > That's not a good thing, IMHO. Or in other case show that such implementation is possible... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote: > On Sun, 29 Nov 2015, Russell King - ARM Linux wrote: > > On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote: > > > Good. And Arnd likes the idea too. So we might be converging at > > > last which is a good thing. > > > > I disagree with the idea that there is convergence. There might be > > convergence towards an idea, but... Here's a mail extract, from > > July 7th, from earlier in this very thread: > > > > Pali: > > > Me: > > > > Are the ATAGs at a fixed address on the N900? > > > > > > Yes, in board-rx51.c is: > > > > > > .atag_offset= 0x100 > > > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > > > Can that be handled in > > > > some kind of legacy file for the N900 which calls save_atags() > > > > on it, so we don't end up introducing yet more stuff that we > > > > have to maintain into the distant future? If not, what about > > > > copying a known working atag structure into a legacy file for > > > > the N900? > > > > > > I already asked question if it is possible to read ATAGs from DT > > > booted kernel. And somebody (do not remember who) wrote to ML, > > > that it is not possible and it can be done in that uncompress > > > code. > > Who is that somebody? If ever it happened to be me then objection is > withdrawn. Otherwise that somebody should come forth and speak up > again. > ... do not remember ... this discussion were in more email threads and takes more then one year... sorry but my memory is not excellent -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Thursday 26 November 2015 12:39:30 Tony Lindgren wrote: > Just to explore options.. How about make a minimal device driver that > just loads the atags blob from /lib/firmware and then shows it in > /proc/atags? Of course some checking on the atags should be done by > the driver.. And who can dynamically create that blob file in /lib/firmware? If kernel does not export those atags (somehow) from bootloader, then userspace is not able to create that blob... cyclic problem. So no, problem is that bootloader provides via custom atags dynamic information like: boot reason (how was device started, by rtc alarm? by reboot? by usb charger? by power button?), boot mode (should be enter into firmware update mode?, is this normal boot mode?), ... and those information are needed for some proprietary software (e.g. firmware upgrade/flash) but also by any other open source applications (based on usb charger we enter different runlevel -- for just only charging device). -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote: > > Or populate /proc/atags only for the ones that need it from machine > > specific init_early? > > This is circling back to the first comment from Russell King where > he suggested a legacy file for the N900 which calls save_atags(): > > Are the ATAGs at a fixed address on the N900? Can that be handled in > some kind of legacy file for the N900 which calls save_atags() on it, so > we don't end up introducing yet more stuff that we have to maintain into > the distant future? If not, what about copying a known working atag > structure into a legacy file for the N900? > > It seems to me that patches 1, 2, 4, and 5 could be replaced by this > approach. Hi Frank, in this case I will ask my question again: It is possible to read atags from that legacy file. And if yes how? I was not thinking about this approach because somebody in past wrote that this is not possible... -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 22:29:53 Arnd Bergmann wrote: > On Wednesday 25 November 2015 13:03:10 Tony Lindgren wrote: > > * Arnd Bergmann <a...@arndb.de> [151125 11:50]: > > > On Wednesday 25 November 2015 10:16:44 Tony Lindgren wrote: > > > > At least I don't have better solutions in mind. > > > > > > I would be happier if we could restrict this as much as possible > > > to the boards that need it, as an opt-in. That way it doesn't > > > become an ABI for people that don't already rely in this > > > information. How about adding a check the code adds the > > > linux,atags property to do it only for a whitelist of board > > > numbers? > > > > Or populate /proc/atags only for the ones that need it from machine > > specific init_early? > > That would also address my main concern about /proc/atags, but still > leave the atags in /proc/device-tree/chosen/linux,atags, and it would > be bad if someone who currently uses /proc/atags changes their code > to use the other file instead of finding a proper solution. > > Arnd Arnd, my question about proper solution reminds... Proprietary bootloader which cannot be replaced (e.g. it is signed or do unknown magic) provides information to booted kernel via custom specific ATAGs fields. How userspace could properly read those custom information from bootloader? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 22:51:00 Arnd Bergmann wrote: > On Wednesday 25 November 2015 22:44:28 Pali Rohár wrote: > > Arnd, my question about proper solution reminds... Proprietary > > bootloader which cannot be replaced (e.g. it is signed or do > > unknown magic) provides information to booted kernel via custom > > specific ATAGs fields. How userspace could properly read those > > custom information from bootloader? > > The typical solution for nonstandard bootloaders is to have a boot > wrapper like the one from > https://github.com/zonque/pxa-impedance-matcher that translates > whatever information we have at the bootloader level into DT > properties. > Ok. So there is no better solution. With some hacks we can use U-Boot as 3rd stage bootloader. But this is not useful for debugging or developing... Ideal "wrapper" solution would be to compile wrapper and linux zImage and then glue them together to one binary. Something like internal linux uncompress code which translate atags to dt. > As I understand, the reason we are not doing that here is that we > also have proprietary user space that we can't fix to look in a > different place, i.e. the interface is between the bootloader and > some user binary, not bootloader to kernel. > Yes, proprietary/closed applications are problems which we cannot fix (without rewriting them). New applications could use new "proper" interface. But without that interface we cannot do that. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Sunday 22 November 2015 07:51:46 Pavel Machek wrote: > On Wed 2015-11-11 17:10:46, Frank Rowand wrote: > > Adding devicetree list. > > > > Thread starts at > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/354459.html > > > > On 11/5/2015 8:17 AM, Tony Lindgren wrote: > > > * Pali Rohár <pali.ro...@gmail.com> [151105 03:41]: > > >> On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote: > > >>> On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: > > >>>> * Pali Rohár <pali.ro...@gmail.com> [151012 13:29]: > > >>>>> On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: > > >>>>>> > > >>>>>> Pali, any news on posting an updated series with the comments > > >>>>>> addressed in this thread? It seems that we all pretty much agree > > >>>>>> what needs to be done. > > > > I'm not real happy with the concept of patches 4 and 5 in this series. > > My concern is that those two patches are using the FDT as a transport > > mechanism for a binary blob (the atags object). > > Umm. Ok. Do you have alternative proposal that works for everyone? > > I mean. This discussion was going for quite a long time, and it would > be nice to have some solution... patch proposal... something. > Pavel Yes, discussion is going for a long time! So should I spend time for adding documentation to my solution (this is last one thing which is missing)? Or my solution is wrong and somebody else will propose new? I do not want to spend time on something which will be rejected and discarded. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Tuesday 13 October 2015 16:37:46 Pali Rohár wrote: > On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: > > * Pali Rohár <pali.ro...@gmail.com> [151012 13:29]: > > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: > > > > > > > > Pali, any news on posting an updated series with the comments > > > > addressed in this thread? It seems that we all pretty much agree > > > > what needs to be done. > > > > > > Tony, I'm not really sure what to do. Just wrap 4 and 5 patches into > > > CONFIG_KEXEC? Or something more? > > > > Well for most part your patches are fine, I think there were some > > minor comments on the series. > > > > For the CONFIG_KEXEC dependency, we should just keep the existing > > behavior and keep /proc/atags behind CONFIG_KEXEC. That's all > > I believe :) > > > > Regards, > > > > Tony > > > > > > Ok. I will add CONFIG_KEXEC into atag patches. > > And there is missing documentation for these two new DT properties > (marked as TODO in commit messages). Where to put them? > Tony (or somebody else) ^^^ -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: omap3: keep ssi ports by default
On Wednesday 14 October 2015 13:44:16 Roger Quadros wrote: > Let's keep the SSI ports disabled in the omap3.dtsi to avoid > getting the following noise on the console for boards that don't > use the SSI ports. > > "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)" > > As omap3-n900 uses one SSI port, mark it enabled there. > Sebastian, why is second SSI port disabled on N900? It is not used or in DTS file are missing some definitions? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Monday 12 October 2015 13:45:09 Tony Lindgren wrote: > * Pali Rohár <pali.ro...@gmail.com> [151012 13:29]: > > On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: > > > > > > Pali, any news on posting an updated series with the comments > > > addressed in this thread? It seems that we all pretty much agree > > > what needs to be done. > > > > Tony, I'm not really sure what to do. Just wrap 4 and 5 patches into > > CONFIG_KEXEC? Or something more? > > Well for most part your patches are fine, I think there were some > minor comments on the series. > > For the CONFIG_KEXEC dependency, we should just keep the existing > behavior and keep /proc/atags behind CONFIG_KEXEC. That's all > I believe :) > > Regards, > > Tony > > Ok. I will add CONFIG_KEXEC into atag patches. And there is missing documentation for these two new DT properties (marked as TODO in commit messages). Where to put them? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe 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 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Monday 12 October 2015 22:16:40 Tony Lindgren wrote: > * Tony Lindgren <t...@atomide.com> [150713 06:21]: > > * Pali Rohár <pali.ro...@gmail.com> [150707 05:00]: > > > On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote: > > > > On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote: > > > > > Legacy bootloaders can pass additional information for kernel > > > > > or legacy userspace applications. When booting DT kernel > > > > > then ATAGs structure is not more visible after running > > > > > kernel uncompress code. This patch stores full ATAGs > > > > > structure into DT "/chosen/linux,atags" entry, so kernel can > > > > > later reuse it and export via /proc/atags to userspace. > > > > > > > > I think you need to go through your commit messages and improve > > > > them, especially the ones with "TODO" in them. As long as > > > > there's still things to be done, they're obviously not ready > > > > for merging. > > > > > > I know, in cover letter email I wrote that documentation is not > > > ready... I send patches for review and comments (like yours). I > > > think it is still better to send something and mark it as > > > incomplete. It could prevent to work on something which will be > > > again rewritten... > > > > > > > Moreover, exporting the ATAGS is questionable, even _if_ there > > > > are non- kexec programs making use of this. The ATAGs have > > > > _never_ been exported to userspace when kexec disabled is the > > > > kernel - it was introduced for kexec, and has always had this: > > > > > > > > config ATAGS_PROC > > > > > > > > bool "Export atags in procfs" > > > > depends on ATAGS && KEXEC > > > > default y > > > > > > > > Now, the fact that someone decided to start using it is pretty > > > > sad, because it means that if you disable KEXEC, userspace > > > > breaks. That's not a kernel regression in any shape or form, > > > > because /proc/atags has never been there without KEXEC > > > > enabled. That's a userspace bug, plain and simple. > > > > > > > > Given that, I'm in two minds about whether to accept the last > > > > two patches which make this more than just "for KEXEC use to > > > > enable a KEXEC kernel to be booted." > > > > > > > > Had it been provided without the KEXEC conditional, then I > > > > don't have a problem with these two patches. > > > > > > I understand it. Nokia originally invented their own entries in > > > /proc/ which export needed ATAGs from kernel in human-readable > > > form, but all those entries were non-standard and specific for > > > Nokia's kernels. > > > > > > Do you have some other idea how to provide ATAGs information > > > created dynamically by legacy closed proprietary bootloader to > > > userspace from DT booted kernel? > > > > > > Anyway, for supporting kexec (with passing ATAGs) it is needed to > > > have working /proc/atags file, right? > > > > Yeah I think that since we already have it in /proc, we should just > > support it. And keep it behind CONFIG_KEXEC and > > CONFIG_ARM_APPENDED_DTB and hope we don't find other users for > > it.. Then reconsider the Kconfig dependencies if we do find other > > users. > > > > > > It also sets a precedent: by adding this into DT, it is > > > > creating a new DT ABI as well, and we'll end up seeing dts > > > > files with an ATAG block patched into them. > > > > > > > > Are the ATAGs at a fixed address on the N900? > > > > > > Yes, in board-rx51.c is: > > > > > > .atag_offset = 0x100 > > > > > > and Nokia Bootloader (proprietary) store them to that address. > > > > > > > Can that be handled in > > > > some kind of legacy file for the N900 which calls save_atags() > > > > on it, so we don't end up introducing yet more stuff that we > > > > have to maintain into the distant future? If not, what about > > > > copying a known working atag structure into a legacy file for > > > > the N900? > > > > > > I already asked question if it is possible to read ATAGs from DT > > > booted kernel. And somebody (do not remember who) wrote to ML, > > > that it is not possible and it can be done in that uncompress > > > code. > > > > I guess the other option would be to keep the raw ATAG area > > reserved, and only initialize /proc/atags from a board specific > > initcall. But I think that would complicate the already fragile > > uncompress relocation code even further? > > Pali, any news on posting an updated series with the comments > addressed in this thread? It seems that we all pretty much agree > what needs to be done. > > Regards, > > Tony Tony, I'm not really sure what to do. Just wrap 4 and 5 patches into CONFIG_KEXEC? Or something more? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: omapdss: Division by zero in kernel
On Thursday 17 September 2015 07:16:44 Pavel Machek wrote:
>
> > > if (image->depth == 1) {
> > > if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
> > > p->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> > > fgcolor =
> > > ((u32*)(p->pseudo_palette))[image->fg_color];
> > > bgcolor =
> > > ((u32*)(p->pseudo_palette))[image->bg_color];
> > > } else {
> > > fgcolor = image->fg_color;
> > > bgcolor = image->bg_color;
> > > }
> > >
> > > if (32 % bpp == 0 && !start_index && !pitch_index &&
> > > ((width & (32/bpp-1)) == 0) &&
> > > bpp >= 8 && bpp <= 32)
> > > fast_imageblit(image, p, dst1, fgcolor, bgcolor);
> > > else
> > > slow_imageblit(image, p, dst1, fgcolor, bgcolor,
> > > start_index, pitch_index);
> > > } else
> > > color_imageblit(image, p, dst1, start_index, pitch_i
> > >
> > >
> > > Notice that bpp is not checked for zero, and thus bpp==0 is totally
> > > feasible? resulting in 32/bpp crashing the kernel?
> > >
> >
> > Hm... this could really be a problem! But how to patch it? Which branch
> > should be called (fast_ or slow_ function) if bpp is zero?
> >
> > And is there some way to force kernel to dump backtrace into dmesg when
> > division by zero occur?
>
> You can do WARN_ON(bpp==1) ... and should probably return in that
> case.
>
> Pavel
Does not make sense to call slow_ function? In that if condition check
also that bpp is nonzero...
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe 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: omapdss: Division by zero in kernel
On Friday 21 August 2015 12:17:41 Tomi Valkeinen wrote: On 21/08/15 11:48, Pali Rohár wrote: On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote: On 24/07/15 19:03, Pali Rohár wrote: Hello, when on N900 (real HW or qemu) I run this command / # echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo 0 /sys/class/graphics/fb0/size then kernel crash with this error message / # [ 29.904113] Division by zero in kernel. Hi! Thanks for explaining. The problem is that fb console uses the kernel mmapped framebuffer, but omapfb is not aware of the fb console. So the above commands free the framebuffer, as omapfb thinks no one is using it, and then fb console tries to touch the fb. What about refusing those calls from fb console? So fb console will not know about this problem and omapfb will just ignore drawn functions? Hmm, I'm not sure I understand what you mean... omapfb is not drawing anything, fbcon is doing the drawing independently to the fb. And the fb suddenly disappears without fbcon realizing that. omapfb tracks mmaps from userspace, and refuses to free a fb it it's mmapped. I don't know how to fix it straight away. Maybe there's a way for omapfb to check if the fbcon uses the fb in question, and if so, refuses to release/resize the memory. Tomi Maemo userspace (on Nokia N900) uses above commands to initialize graphic and Xserver. So it would be nice if disabling framebuffer would work even if fbcon.ko is loaded (or compiled directly into zImage). Ok. And N900 has fbcon enabled? I wonder how it survives... Depends on compiled kernel. Original stock Nokia kernel 2.6.28 has it disabled, but when I recompiled it with fbcon (either static linked into zImage or external fbcon.ko) it works and I do not see any problem. So I think it survives... fbcon can be unbound from userspace with something like: echo 0 /sys/class/vtconsole/vtcon1/bind After that I think the memory can be freed. But obviously the kernel should not crash here, no question about that. Tomi Maybe just adding that test for zero to prevent division by zero? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: omapdss: Division by zero in kernel
On Friday 21 August 2015 11:42:14 Tomi Valkeinen wrote: On 24/07/15 19:03, Pali Rohár wrote: Hello, when on N900 (real HW or qemu) I run this command / # echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo 0 /sys/class/graphics/fb0/size then kernel crash with this error message / # [ 29.904113] Division by zero in kernel. Hi! Thanks for explaining. The problem is that fb console uses the kernel mmapped framebuffer, but omapfb is not aware of the fb console. So the above commands free the framebuffer, as omapfb thinks no one is using it, and then fb console tries to touch the fb. What about refusing those calls from fb console? So fb console will not know about this problem and omapfb will just ignore drawn functions? omapfb tracks mmaps from userspace, and refuses to free a fb it it's mmapped. I don't know how to fix it straight away. Maybe there's a way for omapfb to check if the fbcon uses the fb in question, and if so, refuses to release/resize the memory. Tomi Maemo userspace (on Nokia N900) uses above commands to initialize graphic and Xserver. So it would be nice if disabling framebuffer would work even if fbcon.ko is loaded (or compiled directly into zImage). -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: omapdss: Division by zero in kernel
On Tuesday 18 August 2015 07:11:27 Peter Teoh wrote:
On Fri, Jul 24, 2015 at 9:03 AM, Pali Rohár pali.ro...@gmail.com wrote:
Hello,
when on N900 (real HW or qemu) I run this command
/ # echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo 0
/sys/class/graphics/fb0/size
then kernel crash with this error message
/ # [ 29.904113] Division by zero in kernel.
** 3375 printk messages dropped ** [ 29.963836] [c01e0008]
(__aeabi_uidivmod) from [c022071c]
(cfb_imageblit+0xac/0x464)
** 8426 printk messages dropped ** [ 30.111083] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 8380 printk messages dropped ** [ 30.258209] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 7813 printk messages dropped ** [ 30.400054] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 7666 printk messages dropped ** [ 30.538391] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 7687 printk messages dropped ** [ 30.676544] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 7960 printk messages dropped ** [ 30.819915] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 8317 printk messages dropped ** [ 30.966979] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 8590 printk messages dropped ** [ 31.122528] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 8885 printk messages dropped ** [ 31.287658] [c0218ed0]
(fbcon_scroll) from [c025af90] (scrup+0x60/0x128)
** 9408 printk messages dropped ** [ 31.461425] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 9787 printk messages dropped ** [ 31.644287] [c02187e8]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 10081 printk messages dropped ** [ 31.833984] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 10501 printk messages dropped ** [ 32.031066] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 10816 printk messages dropped ** [ 32.233001] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 10900 printk messages dropped ** [ 32.440490] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.645233] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 32.848999] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 10837 printk messages dropped ** [ 33.053833] [c02187a4]
(fbcon_redraw.isra.12) from [c0218ed0]
(fbcon_scroll+0x6a0/0xcbc)
** 10838 printk messages dropped ** [ 33.258361] [c0218ed0]
(fbcon_scroll) from [c025af90] (scrup+0x60/0x128)
I suspect that problem is in omapdss.
I do not know if size 0 make sense, but Maemo userspace is calling above
commands and on Nokia's 2.6.28 kernel there is no crash or error message.
IMHO Division by zero in kernel should not be there even if userspace
call incorrect command.
--
Pali Rohár
pali.ro...@gmail.com
Not sure if my analysis is correct. According to the recent pull
(4.2.0-rc4+), the code is still vulnerable to this division by zero:
Inside drivers/video/fbdev/core/cfbimgblt.c:
void cfb_imageblit(struct fb_info *p, const struct fb_image *image)
{
u32 fgcolor, bgcolor, start_index, bitstart, pitch_index = 0;
u32 bpl = sizeof(u32), bpp = p-var.bits_per_pixel;
u32 width = image-width;
u32 dx = image-dx, dy = image-dy;
u8 __iomem *dst1;
if (p-state != FBINFO_STATE_RUNNING)
return;
bitstart = (dy * p-fix.line_length * 8) + (dx * bpp);
start_index = bitstart (32 - 1);
pitch_index = (p-fix.line_length (bpl - 1)) * 8;
bitstart /= 8;
bitstart = ~(bpl - 1);
dst1 = p-screen_base + bitstart;
if (p-fbops-fb_sync)
p-fbops-fb_sync(p);
if (image-depth == 1) {
if (p-fix.visual == FB_VISUAL_TRUECOLOR ||
p-fix.visual == FB_VISUAL_DIRECTCOLOR) {
fgcolor =
((u32*)(p-pseudo_palette))[image-fg_color];
bgcolor =
((u32*)(p-pseudo_palette))[image-bg_color];
} else {
fgcolor = image-fg_color;
bgcolor = image-bg_color;
}
if (32 % bpp == 0 !start_index !pitch_index
((width (32/bpp-1)) == 0)
bpp = 8 bpp = 32)
fast_imageblit(image, p, dst1, fgcolor, bgcolor
Re: omapdss: Division by zero in kernel
On Tuesday 28 July 2015 13:56:02 Pali Rohár wrote: On Friday 24 July 2015 18:03:42 Pali Rohár wrote: Hello, when on N900 (real HW or qemu) I run this command / # echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo 0 /sys/class/graphics/fb0/size then kernel crash with this error message / # [ 29.904113] Division by zero in kernel. ** 3375 printk messages dropped ** [ 29.963836] [c01e0008] (__aeabi_uidivmod) from [c022071c] (cfb_imageblit+0xac/0x464) ** 8426 printk messages dropped ** [ 30.111083] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8380 printk messages dropped ** [ 30.258209] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7813 printk messages dropped ** [ 30.400054] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7666 printk messages dropped ** [ 30.538391] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7687 printk messages dropped ** [ 30.676544] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7960 printk messages dropped ** [ 30.819915] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8317 printk messages dropped ** [ 30.966979] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8590 printk messages dropped ** [ 31.122528] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8885 printk messages dropped ** [ 31.287658] [c0218ed0] (fbcon_scroll) from [c025af90] (scrup+0x60/0x128) ** 9408 printk messages dropped ** [ 31.461425] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 9787 printk messages dropped ** [ 31.644287] [c02187e8] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10081 printk messages dropped ** [ 31.833984] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10501 printk messages dropped ** [ 32.031066] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10816 printk messages dropped ** [ 32.233001] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10900 printk messages dropped ** [ 32.440490] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 32.645233] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 32.848999] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 33.053833] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10838 printk messages dropped ** [ 33.258361] [c0218ed0] (fbcon_scroll) from [c025af90] (scrup+0x60/0x128) I suspect that problem is in omapdss. I do not know if size 0 make sense, but Maemo userspace is calling above commands and on Nokia's 2.6.28 kernel there is no crash or error message. IMHO Division by zero in kernel should not be there even if userspace call incorrect command. PING! Any idea what to do with Division by zero in kernel? PING again! Can somebody look at this Division by zero in kernel? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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
On Friday 14 August 2015 22:46:49 Pavel Machek wrote: Hi! Maybe some power management problem? Something is not always initialized correctly? I remember that there is some problem (maybe in NoLo - Nokia bootloader) that sometimes chainloaded U-Boot (booted via NoLo) is not able to initialize mmc chip (all read operation fails). In U-Boot I added some code to enable some parts in twl4030 regulator and after that mmc is working always... Could I get some details? Thay code should be moved to kernel, I'd really like mmc to work, no matter how machine was booted. Best regards, Pavel I think I was inspirited by kernel code when I added that functionality into u-boot... But I do not remember which kernel version... If you are interested and what to play with that, just look at few lines of twl4030 code in uboot rx51.c (until restore I2C access state): http://git.denx.de/?p=u-boot.git;a=blob;f=board/nokia/rx51/rx51.c;h=3d019b01428b5392fb5d0b8c7428a6d1d2ba31af;hb=HEAD#l388 All are just i2c calls to twl4030 chipset. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: Nokia N900 - audio TPA6130A2 problems
On Monday 03 August 2015 20:48:28 Jarkko Nikula wrote: On 08/03/2015 09:17 PM, Pali Rohár wrote: On Monday 03 August 2015 20:03:16 Jarkko Nikula wrote: Hi On 08/01/2015 01:18 PM, Pali Rohár wrote: On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote: Hello, your patch did not helped. Problem is still there... For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to headphones. Don't know were there any i2c etc regression before it or how easy it would be to reproduce. Did you tested it on Nokia N900? Or other device? N900. Seems to be only user of TPA6130A2 in mainline :-) Great, can you do more tests? I get this error often after I reboot N900 (without power off) more times. But no idea if this is just sometimes. Logs below made me thinking can it be a HW issue? Although if it is an HW issue it shouldn't work sometimes I guess. Do you have any earlier well known configuration you could try is it an SW regression or something else? Stock Nokia's 2.6.28 kernel works always. With that kernel I have never seen this problem. So I do not think this is HW problem. This problem is there in more kernel versions, maybe in some older (like v3.5) is was there not so often. But do not remember correctly... 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. Do you still have these pre 3.x kernels? This could be good starting point as 2.6.28 kernel is tooo old and heavily patches... Maybe some power management problem? Something is not always initialized correctly? I remember that there is some problem (maybe in NoLo - Nokia bootloader) that sometimes chainloaded U-Boot (booted via NoLo) is not able to initialize mmc chip (all read operation fails). In U-Boot I added some code to enable some parts in twl4030 regulator and after that mmc is working always... 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. We should know which devices are connected to which i2c bus. So maybe detecting which i2c device is incorrectly initialized? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: Nokia N900 - audio TPA6130A2 problems
On Monday 03 August 2015 20:03:16 Jarkko Nikula wrote:
Hi
On 08/01/2015 01:18 PM, Pali Rohár wrote:
On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote:
On 07/25/2015 12:28 PM, Pali Rohár wrote:
Hello,
sometimes after rebooting Nokia N900 initializing alsa audio
fails. Here output from dmesg log when it happen:
[6.925140] tpa6130a2 2-0060: Write failed
[6.929534] tpa6130a2 2-0060: Failed to initialize chip
[6.935272] tpa6130a2: probe of 2-0060 failed with error -121
[7.624237] rx51-audio n900-audio: Failed to add TPA6130A2
controls [7.635101] rx51-audio n900-audio: ASoC: failed to
init TLV320AIC34: -19 [7.645874] rx51-audio n900-audio: ASoC:
failed to instantiate card -19 [7.665740] rx51-audio
n900-audio: snd_soc_register_card failed (-19) [8.063049]
ALSA device list:
[8.070343] No soundcards found.
Any idea what to do?
Looks like the chip is not responding. Try to add a small delay
after powerup to give the device to be fully ready, something
like the following:
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -152,6 +152,8 @@ static int tpa6130a2_power(u8 power)
if (data-power_gpio = 0)
gpio_set_value(data-power_gpio, 1);
+ msleep(5);
+
data-power_state = 1;
ret = tpa6130a2_initialize();
if (ret 0) {
Hello, your patch did not helped. Problem is still there...
For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to
headphones. Don't know were there any i2c etc regression before it or
how easy it would be to reproduce.
Did you tested it on Nokia N900? Or other device?
Logs below made me thinking can it be a HW issue? Although if it is
an HW issue it shouldn't work sometimes I guess. Do you have any
earlier well known configuration you could try is it an SW
regression or something else?
Stock Nokia's 2.6.28 kernel works always. With that kernel I have never
seen this problem. So I do not think this is HW problem.
This problem is there in more kernel versions, maybe in some older (like
v3.5) is was there not so often. But do not remember correctly...
[5.962585] tpa6130a2 2-0060: Write failed
[5.962707] tpa6130a2 2-0060: Failed to initialize chip
[5.962860] tpa6130a2: probe of 2-0060 failed with error -121
-121 == EREMOTEIO which is returned from i2c-omap.c when there is no
ACK from the chip.
Maybe some power management problem? Something is not always initialized
correctly?
I remember that there is some problem (maybe in NoLo - Nokia bootloader)
that sometimes chainloaded U-Boot (booted via NoLo) is not able to
initialize mmc chip (all read operation fails). In U-Boot I added some
code to enable some parts in twl4030 regulator and after that mmc is
working always...
So maybe something similar? Kernel expects that some PM or regulator
parts are initialized, but they are only sometimes? Just speculation...
[ 28.102233] omap_i2c 48072000.i2c: controller timed out
[ 29.463653] lp5523x 2-0032: lp5523 Programmable led chip found
[ 30.734191] omap_i2c 48072000.i2c: controller timed out waiting
for start condition to finish [ 32.142333] i2c i2c-2: SCL is
stuck low, exit recovery
If SCL is really stuck it also explains why chip doesn't acknowledge.
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: Nokia N900 - audio TPA6130A2 problems
On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote:
On 07/25/2015 12:28 PM, Pali Rohár wrote:
Hello,
sometimes after rebooting Nokia N900 initializing alsa audio fails.
Here output from dmesg log when it happen:
[6.925140] tpa6130a2 2-0060: Write failed
[6.929534] tpa6130a2 2-0060: Failed to initialize chip
[6.935272] tpa6130a2: probe of 2-0060 failed with error -121
[7.624237] rx51-audio n900-audio: Failed to add TPA6130A2
controls [7.635101] rx51-audio n900-audio: ASoC: failed to
init TLV320AIC34: -19 [7.645874] rx51-audio n900-audio: ASoC:
failed to instantiate card -19 [7.665740] rx51-audio
n900-audio: snd_soc_register_card failed (-19) [8.063049] ALSA
device list:
[8.070343] No soundcards found.
Any idea what to do?
Looks like the chip is not responding. Try to add a small delay after
powerup to give the device to be fully ready, something like the
following:
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -152,6 +152,8 @@ static int tpa6130a2_power(u8 power)
if (data-power_gpio = 0)
gpio_set_value(data-power_gpio, 1);
+ msleep(5);
+
data-power_state = 1;
ret = tpa6130a2_initialize();
if (ret 0) {
Hello, your patch did not helped. Problem is still there...
Now I found another problem:
[ 28.102233] omap_i2c 48072000.i2c: controller timed out
Anyway, if you are interested here is full dmesg log:
[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 4.2.0-rc2+ (pali@Pali-Latitude) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #368
PREEMPT Sat Aug 1 12:07:46 CEST 2015
[0.00] CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing
instruction cache
[0.00] Machine model: Nokia N900
[0.00] Memory policy: Data cache writeback
[0.00] On node 0 totalpages: 65280
[0.00] free_area_init_node: node 0, pgdat c069a40c, node_mem_map
cfcf9000
[0.00] Normal zone: 512 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 65280 pages, LIFO batch:15
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] OMAP3430/3530 ES3.1 (l2cache iva sgx neon isp )
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 64768
[0.00] Kernel command line: rootdelay root=/dev/ram0 log_buf_len=20M
[0.00] log_buf_len: 33554432 bytes
[0.00] early log buf free: 64332(98%)
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 203424K/261120K available (4443K kernel code, 308K
rwdata, 1720K rodata, 264K init, 266K bss,
57696K reserved, 0K cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector : 0x - 0x1000 ( 4 kB)
[0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff00 ( 744 MB)
[0.00] lowmem : 0xc000 - 0xd000 ( 256 MB)
[0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB)
[0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB)
[0.00] .text : 0xc0008000 - 0xc060d0c8 (6165 kB)
[0.00] .init : 0xc060e000 - 0xc065 ( 264 kB)
[0.00] .data : 0xc065 - 0xc069d3dc ( 309 kB)
[0.00].bss : 0xc069d3dc - 0xc06dfc4c ( 267 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00] Build-time adjustment of leaf fanout to 32.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 4.0) with 96
interrupts
[0.00] Clocking rate (Crystal/Core/MPU): 19.2/332/500 MHz
[0.00] OMAP clockevent source: timer1 at 32768 Hz
[0.00] clocksource: 32k_counter: mask: 0x max_cycles:
0x, max_idle_ns: 58327039986419 ns
[0.00] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every
6553584741ns
[0.00] OMAP clocksource: 32k_counter at 32768 Hz
[0.000305] Console: colour dummy device 80x30
[0.001586] console [tty0] enabled
[0.001647] Calibrating delay loop... 496.43 BogoMIPS (lpj=2482176)
[0.048828] pid_max: default: 32768 minimum: 301
[0.048980] Security Framework initialized
[0.049102] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[0.049163] Mountpoint-cache hash table entries: 1024
Re: linux 4.2-rc1 broken Nokia N900
On Saturday 25 July 2015 10:55:50 Pali Rohár wrote:
On Wednesday 22 July 2015 04:03:07 Sebastian Reichel wrote:
Hi,
On Tue, Jul 21, 2015 at 07:17:41PM -0500, Michael Welling wrote:
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
This code has my head spinning.
I found that the errors do not occur when the driver is built into
the kernel.
I also found that with the patch below the errors go away.
Not sure if it is acceptible but see if it fixes things on your
side.
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index cf8b91b..3164d13 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
if (!spi-max_speed_hz)
spi-max_speed_hz = spi-master-max_speed_hz;
- spi_set_cs(spi, false);
-
if (spi-master-setup)
status = spi-master-setup(spi);
+ spi_set_cs(spi, false);
+
dev_dbg(spi-dev, setup mode %d, %s%s%s%s%u bits/w, %u Hz max
-- %d\n,
(int) (spi-mode (SPI_CPOL | SPI_CPHA)),
(spi-mode SPI_CS_HIGH) ? cs_high, : ,
mh. maybe a runtime PM issue?
* external abort on non-linefetch: address cannot be accessed,
since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit
faster (module must not be loaded from filesystem), so that
the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup
routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a
prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to
suspend after the runtime PM acquisition in setup()
So I suggest trying the following (compile tested only) patch:
-- Sebastian
diff --git a/drivers/spi/spi-omap2-mcspi.c
b/drivers/spi/spi-omap2-mcspi.c index 5867384..f7d9ffd 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi *mcspi =
spi_master_get_devdata(spi-master); u32 l;
/* The controller handles the inverted chip selects
@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device
*spi, bool enable) enable = !enable;
if (spi-controller_state) {
+ pm_runtime_get_sync(mcspi-dev);
+
l = mcspi_cached_chconf0(spi);
if (enable)
@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device
*spi, bool enable) l |= OMAP2_MCSPI_CHCONF_FORCE;
mcspi_write_chconf0(spi, l);
+
+ pm_runtime_mark_last_busy(mcspi-dev);
+ pm_runtime_put_autosuspend(mcspi-dev);
}
}
This patch fix spi bus for me.
Tested-by: Pali Rohár pali.ro...@gmail.com
Sebastian or Michael: Can you add check for pm_runtime_get_sync()
function and send patch for including in mainline kernel?
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe 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: omapdss: Division by zero in kernel
On Friday 24 July 2015 18:03:42 Pali Rohár wrote: Hello, when on N900 (real HW or qemu) I run this command / # echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo 0 /sys/class/graphics/fb0/size then kernel crash with this error message / # [ 29.904113] Division by zero in kernel. ** 3375 printk messages dropped ** [ 29.963836] [c01e0008] (__aeabi_uidivmod) from [c022071c] (cfb_imageblit+0xac/0x464) ** 8426 printk messages dropped ** [ 30.111083] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8380 printk messages dropped ** [ 30.258209] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7813 printk messages dropped ** [ 30.400054] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7666 printk messages dropped ** [ 30.538391] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7687 printk messages dropped ** [ 30.676544] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7960 printk messages dropped ** [ 30.819915] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8317 printk messages dropped ** [ 30.966979] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8590 printk messages dropped ** [ 31.122528] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8885 printk messages dropped ** [ 31.287658] [c0218ed0] (fbcon_scroll) from [c025af90] (scrup+0x60/0x128) ** 9408 printk messages dropped ** [ 31.461425] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 9787 printk messages dropped ** [ 31.644287] [c02187e8] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10081 printk messages dropped ** [ 31.833984] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10501 printk messages dropped ** [ 32.031066] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10816 printk messages dropped ** [ 32.233001] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10900 printk messages dropped ** [ 32.440490] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 32.645233] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 32.848999] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 33.053833] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10838 printk messages dropped ** [ 33.258361] [c0218ed0] (fbcon_scroll) from [c025af90] (scrup+0x60/0x128) I suspect that problem is in omapdss. I do not know if size 0 make sense, but Maemo userspace is calling above commands and on Nokia's 2.6.28 kernel there is no crash or error message. IMHO Division by zero in kernel should not be there even if userspace call incorrect command. PING! Any idea what to do with Division by zero in kernel? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Tuesday 28 July 2015 14:26:13 Sebastian Reichel wrote: Hi Pali, On Tue, Jul 28, 2015 at 10:39:32AM +0200, Pali Rohár wrote: Sebastian or Michael: Can you add check for pm_runtime_get_sync() function and send patch for including in mainline kernel? This actually already happened before your Tested-By. I accidently did not CC you, sorry for that: https://lkml.org/lkml/2015/7/22/581 https://git.kernel.org/cgit/linux/kernel/git/broonie/spi.git/commit/?h=for-linusid=5f74db105b1c0980c9863e7a7d1bc0525e0316e8 -- Sebastian Ok, so it will be fixed in 4.2. Thanks! -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: n900 in 4.2-rc0: repeating oopses
On Monday 27 July 2015 00:31:19 Pavel Machek wrote: On Wed 2015-07-01 23:16:21, Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [150701 06:11]: On Wed 2015-07-01 03:34:22, Tony Lindgren wrote: Works for me after enabling the idle timeouts with the following script and blanking the screen and disconnecting USB: Um. I'm forcing suspend with echo mem /sys/power/state . (It worked in 4.1). That should just make it sleep, no autosuspend-related trickery... (But yes, I guess I should set up the leds and try autosuspend, too.) That too works just fine for me with omap2plus_defconfig after echo enabled /sys/class/tty/ttyO2/power/wakeup as I have n900 in my test rack. Going through that. AFAICT, you are not using devicetree on n900? CONFIG_MACH_NOKIA_RX51=y Unfortunately, not having serials, it is tricky to get any output from that cnofiguration, so I don't know what I got wrong... Pavel You can try to test it in qemu. It has emulation also of serial. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Wednesday 22 July 2015 04:03:07 Sebastian Reichel wrote:
Hi,
On Tue, Jul 21, 2015 at 07:17:41PM -0500, Michael Welling wrote:
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
This code has my head spinning.
I found that the errors do not occur when the driver is built into
the kernel.
I also found that with the patch below the errors go away.
Not sure if it is acceptible but see if it fixes things on your
side.
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index cf8b91b..3164d13 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
if (!spi-max_speed_hz)
spi-max_speed_hz = spi-master-max_speed_hz;
- spi_set_cs(spi, false);
-
if (spi-master-setup)
status = spi-master-setup(spi);
+ spi_set_cs(spi, false);
+
dev_dbg(spi-dev, setup mode %d, %s%s%s%s%u bits/w, %u Hz max
-- %d\n,
(int) (spi-mode (SPI_CPOL | SPI_CPHA)),
(spi-mode SPI_CS_HIGH) ? cs_high, : ,
mh. maybe a runtime PM issue?
* external abort on non-linefetch: address cannot be accessed,
since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit
faster (module must not be loaded from filesystem), so that
the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup
routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a
prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to
suspend after the runtime PM acquisition in setup()
So I suggest trying the following (compile tested only) patch:
-- Sebastian
diff --git a/drivers/spi/spi-omap2-mcspi.c
b/drivers/spi/spi-omap2-mcspi.c index 5867384..f7d9ffd 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi *mcspi =
spi_master_get_devdata(spi-master); u32 l;
/* The controller handles the inverted chip selects
@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device
*spi, bool enable) enable = !enable;
if (spi-controller_state) {
+ pm_runtime_get_sync(mcspi-dev);
+
l = mcspi_cached_chconf0(spi);
if (enable)
@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device
*spi, bool enable) l |= OMAP2_MCSPI_CHCONF_FORCE;
mcspi_write_chconf0(spi, l);
+
+ pm_runtime_mark_last_busy(mcspi-dev);
+ pm_runtime_put_autosuspend(mcspi-dev);
}
}
This patch fix spi bus for me.
Tested-by: Pali Rohár pali.ro...@gmail.com
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Nokia N900 - audio TPA6130A2 problems
Hello, sometimes after rebooting Nokia N900 initializing alsa audio fails. Here output from dmesg log when it happen: [6.925140] tpa6130a2 2-0060: Write failed [6.929534] tpa6130a2 2-0060: Failed to initialize chip [6.935272] tpa6130a2: probe of 2-0060 failed with error -121 [7.624237] rx51-audio n900-audio: Failed to add TPA6130A2 controls [7.635101] rx51-audio n900-audio: ASoC: failed to init TLV320AIC34: -19 [7.645874] rx51-audio n900-audio: ASoC: failed to instantiate card -19 [7.665740] rx51-audio n900-audio: snd_soc_register_card failed (-19) [8.063049] ALSA device list: [8.070343] No soundcards found. Any idea what to do? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: linux 4.2-rc1 broken Nokia N900
On Friday 24 July 2015 16:18:09 Dave Young wrote: On 07/11/15 at 02:05pm, Pali Rohár wrote: Hello, now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops... Basically wifi, touchscreen and rtc drivers not working... Pali, could you tell how do you test mainline kernel on n900? I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop. I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel? Thanks Dave Hi! Starting Maemo with mainline kernel is not possible. But you can patch Maemo (userspace) and apply some kernel patches and you could boot Maemo system with Hildon UI. You need: Patched kernel: https://github.com/pali/linux-n900 CSSU-devel: https://wiki.maemo.org/CSSU http://talk.maemo.org/showthread.php?t=84292 Open source battery management: http://talk.maemo.org/showthread.php?t=93183 Fixup for Dialer application (rtcom-call-ui): Fixing HAL path /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input Fixup for SGX video driver: Fixing script /etc/event.d/sgx If you do not know how to fix HAL SGX script I can send you later needed information. But I do not know them right now. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Friday 24 July 2015 18:33:51 Dave Young wrote: Hi, Pali On 07/24/15 at 10:40am, Pali Rohár wrote: On Friday 24 July 2015 16:18:09 Dave Young wrote: On 07/11/15 at 02:05pm, Pali Rohár wrote: Hello, now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops... Basically wifi, touchscreen and rtc drivers not working... Pali, could you tell how do you test mainline kernel on n900? I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop. I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel? Thanks Dave Hi! Starting Maemo with mainline kernel is not possible. But you can patch Maemo (userspace) and apply some kernel patches and you could boot Maemo system with Hildon UI. So I think mainline miss some patches in your linux-n900, I guess they are for SGX graphic driver? Yes. Status of kernel driver is here: http://elinux.org/N900 You need: Patched kernel: https://github.com/pali/linux-n900 CSSU-devel: https://wiki.maemo.org/CSSU http://talk.maemo.org/showthread.php?t=84292 Open source battery management: http://talk.maemo.org/showthread.php?t=93183 Fixup for Dialer application (rtcom-call-ui): Fixing HAL path /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input Fixup for SGX video driver: Fixing script /etc/event.d/sgx If you do not know how to fix HAL SGX script I can send you later needed information. But I do not know them right now. Yes, appreciated for that, just at anytime later you find it. I have no much time either, so I believe first I need a lot of spare time to read the threads you mentioned. Thanks Dave Just first post of those threads should be enough. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Friday 24 July 2015 18:28:44 Dave Young wrote: On 07/24/15 at 11:30am, Ivaylo Dimitrov wrote: On 24.07.2015 11:18, Dave Young wrote: Pali, could you tell how do you test mainline kernel on n900? I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop. I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel? Thanks Dave http://talk.maemo.org/showpost.php?p=1459970postcount=142 This is the last (almost) upstream kernel I tried, unfortunately recently I am very short on spare time, so cannot confirm for 4.x kernels, but in theory those should work as well. The kernel tree was on gitorious, but it is down now(I have a local copy). However, all of the needed patches should be on https://github.com/pali/linux-n900. Ivaylo, thanks for your info. I know pali's kernel tree, but the problem is I do not know much about the userspace fixes. According to another reply from Pali, I should fix HAL and sgx start script. Thanks Dave It is not enough, also you need to update Maemo to CSSU-devel version and install BME replacement stuff (open source battery management). -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Friday 24 July 2015 10:40:58 Pali Rohár wrote: On Friday 24 July 2015 16:18:09 Dave Young wrote: On 07/11/15 at 02:05pm, Pali Rohár wrote: Hello, now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops... Basically wifi, touchscreen and rtc drivers not working... Pali, could you tell how do you test mainline kernel on n900? I used to use n900 as a usb dbgp gadget with a backport patch to 2.6.28 so that I can get early debug kernel message from my laptop. I tried mainline previously with Fedora arm, text mode works but no graphics. Is there a way to use maemo UI with mainline kernel? Thanks Dave Hi! Starting Maemo with mainline kernel is not possible. But you can patch Maemo (userspace) and apply some kernel patches and you could boot Maemo system with Hildon UI. You need: Patched kernel: https://github.com/pali/linux-n900 CSSU-devel: https://wiki.maemo.org/CSSU http://talk.maemo.org/showthread.php?t=84292 Open source battery management: http://talk.maemo.org/showthread.php?t=93183 Fixup for Dialer application (rtcom-call-ui): Fixing HAL path /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input Create new file /etc/event.d/userspace-fixes with content: start on started hildon-desktop service console none script if ! hal-device /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input 2 /dev/null; then hal-device --add /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input /dev/null hal-set-property --udi /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input --key input.jack.type -- strlist-pre a hal-set-property --udi /org/freedesktop/Hal/devices/platform_soc_audio_logicaldev_input --key input.jack.type -- strlist-rem a fi end script Fixup for SGX video driver: Fixing script /etc/event.d/sgx Change if condition to: if [ -n $(grep RX-51 /proc/component_version) ] uname -r | grep -q '^2.'; then -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
omapdss: Division by zero in kernel
Hello, when on N900 (real HW or qemu) I run this command / # echo 0 /sys/devices/platform/omapdss/overlay0/enabled echo 0 /sys/class/graphics/fb0/size then kernel crash with this error message / # [ 29.904113] Division by zero in kernel. ** 3375 printk messages dropped ** [ 29.963836] [c01e0008] (__aeabi_uidivmod) from [c022071c] (cfb_imageblit+0xac/0x464) ** 8426 printk messages dropped ** [ 30.111083] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8380 printk messages dropped ** [ 30.258209] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7813 printk messages dropped ** [ 30.400054] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7666 printk messages dropped ** [ 30.538391] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7687 printk messages dropped ** [ 30.676544] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 7960 printk messages dropped ** [ 30.819915] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8317 printk messages dropped ** [ 30.966979] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8590 printk messages dropped ** [ 31.122528] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 8885 printk messages dropped ** [ 31.287658] [c0218ed0] (fbcon_scroll) from [c025af90] (scrup+0x60/0x128) ** 9408 printk messages dropped ** [ 31.461425] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 9787 printk messages dropped ** [ 31.644287] [c02187e8] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10081 printk messages dropped ** [ 31.833984] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10501 printk messages dropped ** [ 32.031066] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10816 printk messages dropped ** [ 32.233001] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10900 printk messages dropped ** [ 32.440490] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 32.645233] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 32.848999] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10837 printk messages dropped ** [ 33.053833] [c02187a4] (fbcon_redraw.isra.12) from [c0218ed0] (fbcon_scroll+0x6a0/0xcbc) ** 10838 printk messages dropped ** [ 33.258361] [c0218ed0] (fbcon_scroll) from [c025af90] (scrup+0x60/0x128) I suspect that problem is in omapdss. I do not know if size 0 make sense, but Maemo userspace is calling above commands and on Nokia's 2.6.28 kernel there is no crash or error message. IMHO Division by zero in kernel should not be there even if userspace call incorrect command. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: linux 4.2-rc1 broken Nokia N900
On Wednesday 22 July 2015 00:13:34 Michael Welling wrote:
On Wed, Jul 22, 2015 at 04:03:07AM +0200, Sebastian Reichel wrote:
Hi,
On Tue, Jul 21, 2015 at 07:17:41PM -0500, Michael Welling wrote:
On Tue, Jul 21, 2015 at 11:34:41AM +0200, Pavel Machek wrote:
This code has my head spinning.
I found that the errors do not occur when the driver is built into the
kernel.
I also found that with the patch below the errors go away.
Not sure if it is acceptible but see if it fixes things on your side.
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index cf8b91b..3164d13 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1801,11 +1801,11 @@ int spi_setup(struct spi_device *spi)
if (!spi-max_speed_hz)
spi-max_speed_hz = spi-master-max_speed_hz;
- spi_set_cs(spi, false);
-
if (spi-master-setup)
status = spi-master-setup(spi);
+ spi_set_cs(spi, false);
+
dev_dbg(spi-dev, setup mode %d, %s%s%s%s%u bits/w, %u Hz max --
%d\n,
(int) (spi-mode (SPI_CPOL | SPI_CPHA)),
(spi-mode SPI_CS_HIGH) ? cs_high, : ,
mh. maybe a runtime PM issue?
mh?
* external abort on non-linefetch: address cannot be accessed,
since the module's clocks are disabled
* built-in works, module not: built-in is probably a little bit
faster (module must not be loaded from filesystem), so that
the device has not yet been suspended
* Before 4.2, omap2_mcspi_set_cs() was called in the setup
routine, which acquired runtime PM
* In 4.2, omap2_mcspi_set_cs() seems to be called without a
prior pm_runtime_get_sync()
* With your workaround, the device has not yet returned to
suspend after the runtime PM acquisition in setup()
So I suggest trying the following (compile tested only) patch:
It seems you are right.
With this patch the SPI drivers no longer cause data aborts.
I will wait for feedback from Pavel and Pali but it looks like
we have a winner.
I'm busy right now for testing something on my N900...
-- Sebastian
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 5867384..f7d9ffd 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
u32 l;
/* The controller handles the inverted chip selects
@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
bool enable)
enable = !enable;
if (spi-controller_state) {
+ pm_runtime_get_sync(mcspi-dev);
+
Should the return code should be checked here as with the other
instances of pm_runtime_get_sync?
Yes, you *must* check return value of pm_runtime_get_sync! Otherwise we
can get another oops/kernel panic. See similar commits:
f7b2b5dd6a62a47e871627c71ed01aa3482154d9
604c31039dae4653f33003d08c91ef58b70b5e63
Anyway, what do you think about adding gcc macro for pm_runtime_get_sync
function which report compiler warning when return value is not checked?
l = mcspi_cached_chconf0(spi);
if (enable)
@@ -263,6 +266,9 @@ static void omap2_mcspi_set_cs(struct spi_device *spi,
bool enable)
l |= OMAP2_MCSPI_CHCONF_FORCE;
mcspi_write_chconf0(spi, l);
+
+ pm_runtime_mark_last_busy(mcspi-dev);
+ pm_runtime_put_autosuspend(mcspi-dev);
}
}
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Wednesday 22 July 2015 15:33:18 Sebastian Reichel wrote:
Hi,
On Wed, Jul 22, 2015 at 09:27:32AM +0200, Pali Rohár wrote:
diff --git a/drivers/spi/spi-omap2-mcspi.c
b/drivers/spi/spi-omap2-mcspi.c
index 5867384..f7d9ffd 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -245,6 +245,7 @@ static void omap2_mcspi_set_enable(const struct
spi_device *spi, int enable)
static void omap2_mcspi_set_cs(struct spi_device *spi, bool enable)
{
+ struct omap2_mcspi *mcspi = spi_master_get_devdata(spi-master);
u32 l;
/* The controller handles the inverted chip selects
@@ -255,6 +256,8 @@ static void omap2_mcspi_set_cs(struct spi_device
*spi, bool enable)
enable = !enable;
if (spi-controller_state) {
+ pm_runtime_get_sync(mcspi-dev);
+
Should the return code should be checked here as with the other
instances of pm_runtime_get_sync?
Yes. If it fails, the line fetch error would be triggered again.
Probably the set_cs callback should also be changed, so that it can
return an error code. This is not something for 4.2-rc, though.
Anyway, what do you think about adding gcc macro for pm_runtime_get_sync
function which report compiler warning when return value is not checked?
Adding __must_check to pm_runtime_get_sync() should be discussed
separately with the relevant people in Cc. A quick grep in drivers/
reveals a huge amount of code not handling pm_runtime_get_sync's return
code.
-- Sebastian
Two times, missing check for pm_runtime_get_sync() cased kernel crash on
Nokia N900. See that crypto commits. I think all drivers which do not
check should be fixed. Otherwise we can see another mysterious problems.
Sebastian, can you CC relevant people? Or maybe start new thread?
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Tuesday 21 July 2015 09:33:00 Pavel Machek wrote: On Tue 2015-07-21 09:31:27, Pavel Machek wrote: On Wed 2015-07-15 15:10:48, Michael Welling wrote: On Wed, Jul 15, 2015 at 09:49:33PM +0200, Pavel Machek wrote: Hi! Ok, so: 4.2-rc1 worked for me, IIRC. This does not make sense. Nothing has changed in drivers/spi between these versions. Are you sure that 4.2-rc1 worked for you? Tested again: yes, I have 4.2-rc1 booted on the device... based on Linus' 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93 . I can push the configs and trees to some public place. Interesting. Something very strange is happening here. Send me the links if you push your tree/config to a public repo. Pushing now. It is on kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 mini-v4.2 Actually, pali, if you have time. I pushed kernel.org:pub/scm/linux/kernel/git/pavel/linux-n900 n900-v4.2 too, that one should work. (Modulo gsm and s2ram). If you could confirm that, that would be great. Best regards, Pavel Ok, I will try it at the weekend... Anyway, can you rebase patches on top of some linus tree? Because via that git.kernel.org web it is impossible to list commits or read diff/patches which you applied. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Monday 20 July 2015 22:46:47 Michael Welling wrote: On Tue, Jul 14, 2015 at 09:14:12AM +0200, Pali Rohár wrote: On Monday 13 July 2015 17:36:07 Michael Welling wrote: On Tue, Jul 14, 2015 at 12:02:44AM +0200, Pali Rohár wrote: I think nothing special. I just call: export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabi- make rx51_defconfig rm -f arch/arm/boot/zImage make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage Where are you getting rx51_defconfig from? This does not appear to be in the kernel source any longer. Can you try the above with omap2plus_defconfig? It is in my linux-n900 repository: https://github.com/pali/linux-n900 Repository contains more n900 specific patches but SPI code is unpatched https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_ defconfig Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration. Has any progress been made on this? Hi, sorry but I did not have time last weekend for testing... Seeing as I was dropped into the middle of this thread, I took a look at the discussion previous. It appears that you are building the drivers as modules. Perhaps I can again attempt to duplicate the issue using modules. Though this should not make a difference. Yes, you can try to build drivers as modules. Also you can try to use my rx51_defconfig. Maybe you find something more... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: linux 4.2-rc1 broken Nokia N900
On Monday 13 July 2015 17:36:07 Michael Welling wrote: On Tue, Jul 14, 2015 at 12:02:44AM +0200, Pali Rohár wrote: I think nothing special. I just call: export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabi- make rx51_defconfig rm -f arch/arm/boot/zImage make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage Where are you getting rx51_defconfig from? This does not appear to be in the kernel source any longer. Can you try the above with omap2plus_defconfig? It is in my linux-n900 repository: https://github.com/pali/linux-n900 Repository contains more n900 specific patches but SPI code is unpatched https://github.com/pali/linux-n900/blob/HEAD/arch/arm/configs/rx51_defconfig Later in week I can try to compile also with omap2plus_defconfig... But in my opinion kernel should not crash with different configuration. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: linux 4.2-rc1 broken Nokia N900
On Sunday 12 July 2015 23:44:25 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150711 05:07]: Hello, now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops... Basically wifi, touchscreen and rtc drivers not working... Here are some relevant snippets form dmesg: [ 13.933959] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09802c [ 13.940490] pgd = cfb38000 [ 13.946594] [fa09802c] *pgd=48011452(bad) [ 13.952758] Internal error: : 1028 [#1] PREEMPT ARM [ 13.958862] Modules linked in: tsc2005(+) omap_sham twl4030_wdt omap_wdt [ 13.965332] CPU: 0 PID: 183 Comm: modprobe Not tainted 4.2.0-rc1+ #363 [ 13.971801] Hardware name: Nokia RX-51 board [ 13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000 [ 13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c [ 13.991485] LR is at spi_set_cs+0x5c/0x60 [ 13.997985] pc : [c02bd3ac]lr : [c02baecc]psr: 2013 [ 13.997985] sp : cb1f3dd0 ip : 0001 fp : 0004 [ 14.011260] r10: cfce5be8 r9 : 0fff r8 : c0654f98 [ 14.017913] r7 : r6 : r5 : r4 : [ 14.024505] r3 : 200103dc r2 : fa098000 r1 : 0001 r0 : cf09bc00 [ 14.031036] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 14.037689] Control: 10c5387d Table: 8fb38019 DAC: 0015 [ 14.044403] Process modprobe (pid: 183, stack limit = 0xcb1f2210) [ 14.051300] Stack: (0xcb1f3dd0 to 0xcb1f4000) [ 14.058105] 3dc0: cf09bc00 c02bafa4 cf09bc00 cf09bc00 [ 14.065277] 3de0: bf013444 bf01254c cf0e2230 cf0e2230 0001 c0654f98 0fff 0fff [ 14.072570] 3e00: 0008 0002 0118 1f40 0031 cf09bc00 ffed bf013444 [ 14.080078] 3e20: 0031 c0654f98 cb1f2000 c02bb5c0 cf09bc00 [ 14.087738] 3e40: bf013454 c027a2f4 cf09bc00 bf013454 bf013454 c027a594 [ 14.095367] 3e60: cf09bc00 cf09bc34 c027a60c bf013454 cb1f3e80 c027a5ac c0278ec8 [ 14.102935] 3e80: cf972c4c cf09d630 bf013454 bf013454 cbb55300 c06848d8 c0279c84 [ 14.110473] 3ea0: bf01327c bf01327d bf013454 cb889180 c0654f98 c027b0c8 [ 14.117980] 3ec0: bf015000 cb889180 c00095b0 0040003e cfe6a080 0040003f [ 14.125457] 3ee0: 0008 cfcf9000 cb1f2000 6013 0040003e cbf1bbc0 0001 [ 14.132843] 3f00: bf0134cc cb1f2000 bf0134c0 cb1f3f58 c04352d0 cf801f00 00d0 [ 14.140136] 3f20: bf0134c0 bf0134c0 416c cb889040 0080 c000ebe4 cb1f2000 c0089f68 [ 14.147308] 3f40: bf0134c0 cbf1bc00 001a9193 416c 001f8d20 c008ab30 d0b1 416c [ 14.154571] 3f60: d0b1267c d0b1252b d0b13514 16c0 1ad0 [ 14.161865] 3f80: 001f 0020 0017 0014 0012 00201208 [ 14.169097] 3fa0: c000ea60 00201208 001f8d20 416c 001a9193 [ 14.176177] 3fc0: 00201208 0080 00208c20 001a9193 bee09e98 [ 14.183197] 3fe0: b6f742b4 bee09ae4 000153f0 93e4 6010 001f8d20 72757463 69665f65 [ 14.190277] [c02bd3ac] (omap2_mcspi_set_cs) from [c02baecc] (spi_set_cs+0x5c/0x60) [ 14.197479] [c02baecc] (spi_set_cs) from [c02bafa4] (spi_setup+0xd4/0x10c) [ 14.204833] [c02bafa4] (spi_setup) from [bf01254c] (tsc2005_probe+0x104/0x484 [tsc2005]) [ 14.212249] [bf01254c] (tsc2005_probe [tsc2005]) from [c02bb5c0] (spi_drv_probe+0x50/0x6c) [ 14.219818] [c02bb5c0] (spi_drv_probe) from [c027a2f4] (really_probe+0xd4/0x230) [ 14.227478] [c027a2f4] (really_probe) from [c027a594] (driver_probe_device+0x30/0x48) [ 14.235290] [c027a594] (driver_probe_device) from [c027a60c] (__driver_attach+0x60/0x84) [ 14.243286] [c027a60c] (__driver_attach) from [c0278ec8] (bus_for_each_dev+0x50/0x84) [ 14.251281] [c0278ec8] (bus_for_each_dev) from [c0279c84] (bus_add_driver+0xcc/0x1e0) [ 14.259246] [c0279c84] (bus_add_driver) from [c027b0c8] (driver_register+0x9c/0xe0) [ 14.267272] [c027b0c8] (driver_register) from [c00095b0] (do_one_initcall+0x100/0x1b0) [ 14.275421] [c00095b0] (do_one_initcall) from [c0089f68] (do_init_module+0x58/0x1bc) [ 14.283477] [c0089f68] (do_init_module) from [c008ab30] (SyS_init_module+0x54/0x64) [ 14.291412] [c008ab30] (SyS_init_module) from [c000ea60] (ret_fast_syscall+0x0/0x3c) [ 14.299407] Code: e5823018 e5902188 e5922000 e582302c (e592302c) [ 14.307403] ---[ end trace d21553dcaefcb5ac ]--- That seems to be a regression with the SPI driver. Care to git bisect it? It's probably one of the following commits: $ git log --pretty=oneline v4.1..v4.2-rc2 drivers/spi/spi-omap2-mcspi.c Looks like just modprobe tsc2005 is enough
Re: linux 4.2-rc1 broken Nokia N900
On Monday 13 July 2015 17:51:39 Sebastian Reichel wrote: Hi, On Sat, Jul 11, 2015 at 02:05:05PM +0200, Pali Rohár wrote: now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops... Basically wifi, touchscreen and rtc drivers not working... I just tried 4.2-rc2 and I can't see any of the problems you have: [2.473968] twl_rtc 4807.i2c:twl@48:rtc: Power up reset detected. [2.481170] twl_rtc 4807.i2c:twl@48:rtc: Enabling TWL-RTC [2.492095] twl_rtc 4807.i2c:twl@48:rtc: rtc core: registered 4807.i2c:twl@48 as rtc0 ... [3.017028] wl1251: loaded [3.022430] wl1251: initialized ... [3.065490] input: TSC2005 touchscreen as /devices/platform/6800.ocp/48098000.spi/spi_master/spi1/spi1.0/input/input5 ... The only thing I noticed is, that the display is not working. For some reason it is not enabled: root@n900:/sys/class/drm/card0-Unknown-2# cat status connected root@n900:/sys/class/drm/card0-Unknown-2# cat modes 800x480 root@n900:/sys/class/drm/card0-Unknown-2# cat enabled disabled -- Sebastian Hi! now I'm testing 4.2-rc2 release and rtc is working: [ 27.426055] omap_i2c 48072000.i2c: controller timed out [ 28.723358] twl_rtc 4807.i2c:twl@48:rtc: Power up reset detected. [ 30.127014] twl_rtc 4807.i2c:twl@48:rtc: Enabling TWL-RTC [ 31.373626] twl_rtc 4807.i2c:twl@48:rtc: rtc core: registered 4807.i2c:twl@48 as rtc0 There is still some i2c time out line and some reset detected, but driver loads fine. But problem with touchscreen tsc2005 and wifi wl1251 is still there :-( Drivers are compiled as external .ko modules. Plus I see new problem with bq2415_charger :-( [ 54.214965] isp1704_charger isp1704: registered with product id isp1707 [ 54.828674] bq2415x-charger 2-006b: automode enabled [ 55.192596] [ cut here ] [ 55.200561] WARNING: CPU: 0 PID: 528 at kernel/workqueue.c:1443 __queue_delayed_work+0x50/0x144() [ 55.208648] Modules linked in: isp1704_charger rx51_battery nokia_h4p lis3lv02d_i2c lis3lv02d input_polldev bluetooth ad5820 bq2415x_charger omap_ssi bq27x00_battery hsi si4713 v4l2_common rtc_twl tsl2563 leds_lp5523 leds_lp55xx_common video_bus_switch videodev media twl4030_vibra ff_memless tsc2005(+) omap_sham twl4030_wdt omap_wdt [ 55.242828] CPU: 0 PID: 528 Comm: kworker/0:3 Tainted: G D W 4.2.0-rc2+ #364 [ 55.251556] Hardware name: Nokia RX-51 board [ 55.260070] Workqueue: events power_supply_changed_work [ 55.268524] [c0013650] (unwind_backtrace) from [c0011bf4] (show_stack+0x10/0x14) [ 55.277099] [c0011bf4] (show_stack) from [c003346c] (warn_slowpath_common+0x84/0xac) [ 55.285675] [c003346c] (warn_slowpath_common) from [c00334ac] (warn_slowpath_null+0x18/0x1c) [ 55.294281] [c00334ac] (warn_slowpath_null) from [c0047bb0] (__queue_delayed_work+0x50/0x144) [ 55.302795] [c0047bb0] (__queue_delayed_work) from [c0047cdc] (queue_delayed_work_on+0x38/0x44) [ 55.319488] [c0047cdc] (queue_delayed_work_on) from [bf0a59e4] (bq2415x_notifier_call+0x90/0x9c [bq2415x_charger]) [ 55.337249] [bf0a59e4] (bq2415x_notifier_call [bq2415x_charger]) from [c004de34] (notifier_call_chain+0x38/0x68) [ 55.355621] [c004de34] (notifier_call_chain) from [c004dff4] (__atomic_notifier_call_chain+0x34/0x44) [ 55.374664] [c004dff4] (__atomic_notifier_call_chain) from [c004e018] (atomic_notifier_call_chain+0x14/0x18) [ 55.394042] [c004e018] (atomic_notifier_call_chain) from [c0305a9c] (power_supply_changed_work+0xac/0x130) [ 55.414245] [c0305a9c] (power_supply_changed_work) from [c00484d8] (process_one_work+0x278/0x45c) [ 55.435302] [c00484d8] (process_one_work) from [c0048918] (worker_thread+0x230/0x354) [ 55.446228] [c0048918] (worker_thread) from [c004d0e0] (kthread+0xcc/0xe0) [ 55.457183] [c004d0e0] (kthread) from [c000eb08] (ret_from_fork+0x14/0x2c) [ 55.468170] ---[ end trace 53c71cbce36f62a7 ]--- [ 55.478912] [ cut here ] [ 55.489501] WARNING: CPU: 0 PID: 528 at kernel/workqueue.c:1445 __queue_delayed_work+0xb4/0x144() [ 55.500213] Modules linked in: isp1704_charger rx51_battery nokia_h4p lis3lv02d_i2c lis3lv02d input_polldev bluetooth ad5820 bq2415x_charger omap_ssi bq27x00_battery hsi si4713 v4l2_common rtc_twl tsl2563 leds_lp5523 leds_lp55xx_common video_bus_switch videodev media twl4030_vibra ff_memless tsc2005(+) omap_sham twl4030_wdt omap_wdt [ 55.543579] CPU: 0 PID: 528 Comm: kworker/0:3 Tainted: G D W 4.2.0-rc2+ #364 [ 55.554565] Hardware name: Nokia RX-51 board [ 55.565307] Workqueue: events power_supply_changed_work [ 55.576049] [c0013650] (unwind_backtrace) from [c0011bf4] (show_stack+0x10/0x14) [ 55.586853] [c0011bf4] (show_stack) from [c003346c] (warn_slowpath_common+0x84/0xac) [ 55.597778] [c003346c] (warn_slowpath_common) from [c00334ac] (warn_slowpath_null+0x18/0x1c) [ 55.608764] [c00334ac
Re: linux 4.2-rc1 broken Nokia N900
On Monday 13 July 2015 19:03:44 Michael Welling wrote: On Mon, Jul 13, 2015 at 10:09:21AM +0200, Sebastian Reichel wrote: [+cc Michael Welling mwell...@ieee.org, author of all omap-spi patches between 4.1 and 4.2-rc1] Hi, On Sun, Jul 12, 2015 at 11:44:25PM -0700, Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150711 05:07]: Hello, now I tested 4.2-rc1 release on Nokia N900 and couple of drivers are broken and cause kernel oops... Basically wifi, touchscreen and rtc drivers not working... Here are some relevant snippets form dmesg: [ 13.933959] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09802c [ 13.940490] pgd = cfb38000 [ 13.946594] [fa09802c] *pgd=48011452(bad) [ 13.952758] Internal error: : 1028 [#1] PREEMPT ARM [ 13.958862] Modules linked in: tsc2005(+) omap_sham twl4030_wdt omap_wdt [ 13.965332] CPU: 0 PID: 183 Comm: modprobe Not tainted 4.2.0-rc1+ #363 [ 13.971801] Hardware name: Nokia RX-51 board [ 13.978302] task: cf572300 ti: cb1f2000 task.ti: cb1f2000 [ 13.984924] PC is at omap2_mcspi_set_cs+0x44/0x4c Here is the disassembly of the omap2_mcspi_set_cs function from my compiler: 0040 omap2_mcspi_set_cs: 40: e2803e25add r3, r0, #592; 0x250 44: e5902258ldr r2, [r0, #600] ; 0x258 48: e1d330b2ldrhr3, [r3, #2] 4c: e3130004tst r3, #4 50: 12211001eorne r1, r1, #1 54: e352cmp r2, #0 58: 012fff1ebxeqlr 5c: e5923018ldr r3, [r2, #24] 60: e351cmp r1, #0 64: 13c33601bicne r3, r3, #1048576; 0x10 68: 03833601orreq r3, r3, #1048576; 0x10 6c: e5823018str r3, [r2, #24] 70: e5902258ldr r2, [r0, #600] ; 0x258 74: e5922000ldr r2, [r2] 78: e582302cstr r3, [r2, #44] ; 0x2c 7c: e5903258ldr r3, [r0, #600] ; 0x258 80: e5933000ldr r3, [r3] 84: e593202cldr r2, [r3, #44] ; 0x2c 88: e12fff1ebx lr The omap2_mcspi_set_cs function is being called before the controller_state is initialized in omap2_mcspi_setup. That is why there is a conditional checking if controller_state is NULL. Perhaps the controller_state is uninitialized but has garbage instead of NULL causing the data abort. Though that does not make much sense because a similar check in the setup function did not cause a data abort in the past. Not sure what is going wrong here. Could you do a objdump with the compiler you are using? Hello, here is my objdump of 4.2-rc2 version: 0064 omap2_mcspi_set_cs: 64: e3003182movwr3, #386; 0x182 68: e19030b3ldrhr3, [r0, r3] 6c: e3130004tst r3, #4 70: 0a01beq 7c omap2_mcspi_set_cs+0x18 74: e2711001rsbsr1, r1, #1 78: 33a01000movcc r1, #0 7c: e5902188ldr r2, [r0, #392] ; 0x188 80: e352cmp r2, #0 84: 012fff1ebxeqlr 88: e5923018ldr r3, [r2, #24] 8c: e351cmp r1, #0 90: 13c33601bicne r3, r3, #1048576; 0x10 94: 03833601orreq r3, r3, #1048576; 0x10 98: e5823018str r3, [r2, #24] 9c: e5902188ldr r2, [r0, #392] ; 0x188 a0: e5922000ldr r2, [r2] a4: e582302cstr r3, [r2, #44] ; 0x2c a8: e592302cldr r3, [r2, #44] ; 0x2c ac: e12fff1ebx lr -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: linux 4.2-rc1 broken Nokia N900
On Monday 13 July 2015 22:28:35 Michael Welling wrote: On Mon, Jul 13, 2015 at 07:09:06PM +0200, Pali Rohár wrote: Hello, here is my objdump of 4.2-rc2 version: 0064 omap2_mcspi_set_cs: 64: e3003182movwr3, #386; 0x182 68: e19030b3ldrhr3, [r0, r3] 6c: e3130004tst r3, #4 70: 0a01beq 7c omap2_mcspi_set_cs+0x18 74: e2711001rsbs r1, r1, #1 78: 33a01000movcc r1, #0 7c: e5902188ldr r2, [r0, #392] ; 0x188 80: e352cmp r2, #0 84: 012fff1ebxeqlr 88: e5923018ldr r3, [r2, #24] 8c: e351cmp r1, #0 90: 13c33601bicne r3, r3, #1048576; 0x10 94: 03833601orreq r3, r3, #1048576 ; 0x10 98: e5823018str r3, [r2, #24] 9c: e5902188ldr r2, [r0, #392] ; 0x188 a0: e5922000ldr r2, [r2] a4: e582302cstr r3, [r2, #44] ; 0x2c a8: e592302cldr r3, [r2, #44] ; 0x2c ac: e12fff1ebx lr I have not been able to duplicate the failure on the hardware that I have. I dug out my old Beagleboard and added an SPI registration to the dts. This was the closest hardware that I had to the N900's processor. What is the version of the gcc compiler you are using and where did you get it from? I'm using gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) from package gcc-4.6-arm-linux-gnueabi which is available on Ubuntu 12.04 LTS (version 4.6.3-1ubuntu5cross1.62). For instance, I am using a 4.9.1 compiler that I built using Yocto. Also are you using devicetree or the old board file board-rx51.c? I'm using devicetree. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: linux 4.2-rc1 broken Nokia N900
On Monday 13 July 2015 23:52:32 Michael Welling wrote: On Mon, Jul 13, 2015 at 10:34:21PM +0200, Pali Rohár wrote: On Monday 13 July 2015 22:28:35 Michael Welling wrote: On Mon, Jul 13, 2015 at 07:09:06PM +0200, Pali Rohár wrote: Hello, here is my objdump of 4.2-rc2 version: 0064 omap2_mcspi_set_cs: 64: e3003182movwr3, #386; 0x182 68: e19030b3ldrhr3, [r0, r3] 6c: e3130004tst r3, #4 70: 0a01beq 7c omap2_mcspi_set_cs+0x18 74: e2711001rsbs r1, r1, #1 78: 33a01000movcc r1, #0 7c: e5902188ldr r2, [r0, #392] ; 0x188 80: e352cmp r2, #0 84: 012fff1ebxeqlr 88: e5923018ldr r3, [r2, #24] 8c: e351cmp r1, #0 90: 13c33601bicne r3, r3, #1048576 ; 0x10 94: 03833601orreq r3, r3, #1048576 ; 0x10 98: e5823018str r3, [r2, #24] 9c: e5902188ldr r2, [r0, #392] ; 0x188 a0: e5922000ldr r2, [r2] a4: e582302cstr r3, [r2, #44] ; 0x2c a8: e592302cldr r3, [r2, #44] ; 0x2c ac: e12fff1ebx lr I have not been able to duplicate the failure on the hardware that I have. I dug out my old Beagleboard and added an SPI registration to the dts. This was the closest hardware that I had to the N900's processor. What is the version of the gcc compiler you are using and where did you get it from? I'm using gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) from package gcc-4.6-arm-linux-gnueabi which is available on Ubuntu 12.04 LTS (version 4.6.3-1ubuntu5cross1.62). I downloaded and compiled with this compiler and it still does not effect the functionality of the targets that I have. What flags (if any) are you passing to the compiler? I think nothing special. I just call: export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabi- make rx51_defconfig rm -f arch/arm/boot/zImage make -j12 zImage modules omap3-n900.dtb CONFIG_DEBUG_SECTION_MISMATCH=y cat arch/arm/boot/zImage arch/arm/boot/dts/omap3-n900.dtb arch/arm/boot/zImage.new mv arch/arm/boot/zImage.new arch/arm/boot/zImage Here is my objdump with gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5): 0074 omap2_mcspi_set_cs: 74: e59f304cldr r3, [pc, #76] ; c8 omap2_mcspi_set_cs+0x54 78: e19030b3ldrhr3, [r0, r3] 7c: e3130004tst r3, #4 80: 0a01beq 8c omap2_mcspi_set_cs+0x18 84: e2711001rsbsr1, r1, #1 88: 33a01000movcc r1, #0 8c: e5903258ldr r3, [r0, #600] ; 0x258 90: e353cmp r3, #0 94: 012fff1ebxeqlr 98: e5932018ldr r2, [r3, #24] 9c: e351cmp r1, #0 a0: 13c22601bicne r2, r2, #1048576; 0x10 a4: 03822601orreq r2, r2, #1048576; 0x10 a8: e5832018str r2, [r3, #24] ac: e5903258ldr r3, [r0, #600] ; 0x258 b0: e5933000ldr r3, [r3] b4: e583202cstr r2, [r3, #44] ; 0x2c b8: e5903258ldr r3, [r0, #600] ; 0x258 bc: e5933000ldr r3, [r3] c0: e593202cldr r2, [r3, #44] ; 0x2c c4: e12fff1ebx lr c8: 0252.word 0x0252 For instance, I am using a 4.9.1 compiler that I built using Yocto. Also are you using devicetree or the old board file board-rx51.c? I'm using devicetree. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
linux 4.2-rc1 broken Nokia N900
] (omap_intc_handle_irq) from [c042c200] (__irq_svc+0x40/0x74) [ 103.817749] Exception stack(0xc912fc80 to 0xc912fcc8) [ 103.827423] fc80: cbd28a00 000b 090c 0001 [ 103.837280] fca0: cfce6b7c 9cb4 c912fcc8 c008c688 c008c780 [ 103.847045] fcc0: 4113 [ 103.856750] [c042c200] (__irq_svc) from [c008c780] (acct_collect+0x174/0x1ac) [ 103.866638] [c008c780] (acct_collect) from [c0035864] (do_exit+0x1d4/0x3c4) [ 103.876434] [c0035864] (do_exit) from [c0011a40] (oops_end+0xc4/0xdc) [ 103.886230] [c0011a40] (oops_end) from [c0009218] (do_DataAbort+0xa0/0xb4) [ 103.896118] [c0009218] (do_DataAbort) from [c042c198] (__dabt_svc+0x38/0x60) [ 103.906066] Exception stack(0xc912fda8 to 0xc912fdf0) [ 103.915832] fda0: cf0e3400 0001 fa0ba000 200103c3 [ 103.925750] fdc0: 003d cfce6b7c 00fa c912fdf0 [ 103.935455] fde0: c02baecc c02bd3ac 2113 [ 103.944885] [c042c198] (__dabt_svc) from [c02bd3ac] (omap2_mcspi_set_cs+0x44/0x4c) [ 103.954376] [c02bd3ac] (omap2_mcspi_set_cs) from [c02baecc] (spi_set_cs+0x5c/0x60) [ 103.963684] [c02baecc] (spi_set_cs) from [c02bafa4] (spi_setup+0xd4/0x10c) [ 103.972930] [c02bafa4] (spi_setup) from [bf2c83f4] (wl1251_spi_probe+0x74/0x224 [wl1251_spi]) [ 103.982299] [bf2c83f4] (wl1251_spi_probe [wl1251_spi]) from [c02bb5c0] (spi_drv_probe+0x50/0x6c) [ 104.000640] [c02bb5c0] (spi_drv_probe) from [c027a2f4] (really_probe+0xd4/0x230) [ 104.010070] [c027a2f4] (really_probe) from [c027a594] (driver_probe_device+0x30/0x48) [ 104.019561] [c027a594] (driver_probe_device) from [c027a60c] (__driver_attach+0x60/0x84) [ 104.029022] [c027a60c] (__driver_attach) from [c0278ec8] (bus_for_each_dev+0x50/0x84) [ 104.038330] [c0278ec8] (bus_for_each_dev) from [c0279c84] (bus_add_driver+0xcc/0x1e0) [ 104.047576] [c0279c84] (bus_add_driver) from [c027b0c8] (driver_register+0x9c/0xe0) [ 104.056793] [c027b0c8] (driver_register) from [c00095b0] (do_one_initcall+0x100/0x1b0) [ 104.066162] [c00095b0] (do_one_initcall) from [c0089f68] (do_init_module+0x58/0x1bc) [ 104.075408] [c0089f68] (do_init_module) from [c008ab30] (SyS_init_module+0x54/0x64) [ 104.084564] [c008ab30] (SyS_init_module) from [c000ea60] (ret_fast_syscall+0x0/0x3c) [ 104.093627] ---[ end trace d21553dcaefcb5af ]--- -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: musb-hdrc: Vbus off, timeout 1100 msec message does not belong in sysfs
On Thursday 09 July 2015 23:46:10 Pavel Machek wrote: On Thu 2015-07-09 23:39:22, Pavel Machek wrote: Hi! sysfs should contain one value per file. This one has at least two, with nice english sentence as a bonus. root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/mu sb-hdrc.0.auto# cat vbus Vbus off, timeout 1100 msec :-(. Plus, documentation for this is nowhere to be seen: pavel@amd:/data/l/linux-n900$ grep -ri musb Documentation/ABI/ pavel@amd:/data/l/linux-n900$ ..which is a shame, because it is not really clear how to use this one: root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb -hdrc.0.auto# cat mode b_idle root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb -hdrc.0.auto# echo a_suspend mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb -hdrc.0.auto# echo a mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb -hdrc.0.auto# echo a_host mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb -hdrc.0.auto# echo b_host mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb -hdrc.0.auto# echo a_idle mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb -hdrc.0.auto# echo b_wait_acon mode -bash: echo: write error: Invalid argument root@n900:/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb -hdrc.0.auto# Pavel Hi! I remember that this file is used for switching between usb peripheral and host mode. But because n900 HW somehow broken, for usb host mode are needed couple of hack patches which workaround HW bugs... This is still not enough and support from userspace is needed for it too. Kernel patches are part of Maemo kernel-power 2.6.28 version and with package usbmode http://maemo.org/packages/view/usbmode/ is it possible to enter usb host mode on n900 (and then connect e.g. usb stick). And IIRC correct command is: # echo host mode # echo peripheral mode -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: USB Ethernet gadget on Nokia n900
On Monday 06 July 2015 06:53:18 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150706 06:27]: On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141028 15:22]: On Tue 2014-10-28 23:04:50, Pavel Machek wrote: Networking now works against 3.17-based kernel. Thanks! It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to apply to 3.17, no changes needed for 3.18-rc1.) Tested-by: Pavel Machek pa...@ucw.cz Whatever we decice to do to fix this regression, it should probably be backported to at least v3.16 stable for distro use, maybe earlier too. I'd assume this is broken on multiple platforms currently. it looks like this patch was not included into any kernel version... I'm still using it on top of 4.x kernels. Are you going to send this patch into upstream? Or do you have another fix for this problem? I think Felipe mentioned a better built-in gether fix that's been reviewed on linux-usb list. Regards, Tony Do you have link to that email thread? Or was Felipe's fix already merged into mainline kernel? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: rx51-battery.ko incompatiblity: board code vs DT
On Tuesday 07 July 2015 17:02:30 Sebastian Reichel wrote: Hi, On Mon, Jul 06, 2015 at 09:44:22PM +0200, Pali Rohár wrote: now I found out that rx51-battery.ko driver register sysnode /sys/class/power_supply/rx51-battery/ when booting with legacy board code. But when booting DT kernel it register sysnode with different name /sys/class/power_supply/n900-battery/ Sysfs node for DT kernel comes from Nokia N900 DTS file: arch/arm/boot/dts/omap3-n900.dts I would propose change which change DTS to rx51-battery to have it compatible with naming which is for legacy board code. It is just because to have compatibility and same naming scheme and also to make existing programs to work without needing patching them. What do you think? Change the driver instead (in rx51_battery_probe): - di-bat.name = dev_name(pdev-dev); + di-bat.name = rx51-battery This will keep the DT ABI stable and avoid introducing the term rx51 in the device tree file. -- Sebastian Perfect, if it works fine can you send apply patch? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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 5/5] arm: boot: store ATAGs structure into DT /chosen/linux,atags entry
On Tuesday 07 July 2015 12:32:13 Russell King - ARM Linux wrote: On Mon, Jul 06, 2015 at 10:26:13PM +0200, Pali Rohár wrote: Legacy bootloaders can pass additional information for kernel or legacy userspace applications. When booting DT kernel then ATAGs structure is not more visible after running kernel uncompress code. This patch stores full ATAGs structure into DT /chosen/linux,atags entry, so kernel can later reuse it and export via /proc/atags to userspace. I think you need to go through your commit messages and improve them, especially the ones with TODO in them. As long as there's still things to be done, they're obviously not ready for merging. I know, in cover letter email I wrote that documentation is not ready... I send patches for review and comments (like yours). I think it is still better to send something and mark it as incomplete. It could prevent to work on something which will be again rewritten... Moreover, exporting the ATAGS is questionable, even _if_ there are non- kexec programs making use of this. The ATAGs have _never_ been exported to userspace when kexec disabled is the kernel - it was introduced for kexec, and has always had this: config ATAGS_PROC bool Export atags in procfs depends on ATAGS KEXEC default y Now, the fact that someone decided to start using it is pretty sad, because it means that if you disable KEXEC, userspace breaks. That's not a kernel regression in any shape or form, because /proc/atags has never been there without KEXEC enabled. That's a userspace bug, plain and simple. Given that, I'm in two minds about whether to accept the last two patches which make this more than just for KEXEC use to enable a KEXEC kernel to be booted. Had it been provided without the KEXEC conditional, then I don't have a problem with these two patches. I understand it. Nokia originally invented their own entries in /proc/ which export needed ATAGs from kernel in human-readable form, but all those entries were non-standard and specific for Nokia's kernels. Do you have some other idea how to provide ATAGs information created dynamically by legacy closed proprietary bootloader to userspace from DT booted kernel? Anyway, for supporting kexec (with passing ATAGs) it is needed to have working /proc/atags file, right? It also sets a precedent: by adding this into DT, it is creating a new DT ABI as well, and we'll end up seeing dts files with an ATAG block patched into them. Are the ATAGs at a fixed address on the N900? Yes, in board-rx51.c is: .atag_offset= 0x100 and Nokia Bootloader (proprietary) store them to that address. Can that be handled in some kind of legacy file for the N900 which calls save_atags() on it, so we don't end up introducing yet more stuff that we have to maintain into the distant future? If not, what about copying a known working atag structure into a legacy file for the N900? I already asked question if it is possible to read ATAGs from DT booted kernel. And somebody (do not remember who) wrote to ML, that it is not possible and it can be done in that uncompress code. -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Thursday 25 June 2015 07:01:38 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150506 04:45]: On Wednesday 06 May 2015 13:04:01 Arnd Bergmann wrote: It needs to be done in this code, so system_rev variable is set properly... What I mean is which code accesses this variable that early? ATAG code is doing it at same early stage, so I added it to same early stage... Yes we should do this early like the other atags. Also, it seems strange to have a string property and then use kstrtouint to convert it into a number. I think it should either be specified in a DT binding to be a string and then have the kernel not assume that it is a number, or we should define it to be binary. Arnd Variable system_rev is number and it always was. So chaning type will break more parts. And it is string DT property to be human readable. Some other developers suggested for v2 to change it to string (from number). Both of them would be human readable, you just use something else to read them ;-) If we have a string here, we should just change all uses of system_rev in the kernel accordingly, there are only a few of them: Let's just keep it as a hex as it was. After all it's an existing interface in /proc that user space programs may expect to be in hex format already. Pali, care to repost the whole set again right after -rc1 with with rev property naming and documentation added? Just keep it as hex and let's forget any string conversion. Regards, Tony Hello Tony, into which file should I put documentation about new DT properties? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Monday 06 July 2015 14:31:27 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Documentation/devicetree/bindings/revision.txt? For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt? Regards, Tony Hm... now I'm thinking into which DT field should I put atags and revision. In previous emails you wrote to use linux,atags, now arm,atags? And put them into root node? Or other? In arch/arm/boot/compressed/atags_to_fdt.c code I see that most atag properties are converted into /chosen node in DT... So what do you prefer for revision and what for atags? Some mentioned examples: /revision /chosen/revision /linux,revision /chosen/linux,revision ... /atags /chosen/atags /linux,atags /chosen/linux,atags /arm,atags /chosen/arm,atags ... -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: USB Ethernet gadget on Nokia n900
On Tuesday 28 October 2014 23:26:41 Tony Lindgren wrote: * Pavel Machek pa...@ucw.cz [141028 15:22]: On Tue 2014-10-28 23:04:50, Pavel Machek wrote: Hi! Here's a patch that should fix the issues for built-in USB gadgets. Pavel, care to see if this gets NFSroot over USB working again for you? It seems to have did the trick for me. (Plus I needed to add +CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y +# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set to be able to control the command line, that's why testing took me a while.) Networking now works against 3.17-based kernel. Thanks! It works on 3.18-rc1 kernel, too. (I had to hand-modify patch to apply to 3.17, no changes needed for 3.18-rc1.) Tested-by: Pavel Machek pa...@ucw.cz Whatever we decice to do to fix this regression, it should probably be backported to at least v3.16 stable for distro use, maybe earlier too. I'd assume this is broken on multiple platforms currently. Regards, Tony Hi Tony, it looks like this patch was not included into any kernel version... I'm still using it on top of 4.x kernels. Are you going to send this patch into upstream? Or do you have another fix for this problem? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH 0/5] ATAGs to DT patches
This patch series converts some legacy ATAGs into DT and provide them to userspace. It is needed for userspace applications which needs some informations from legacy bootloaders which are not DT compatible. Patch series is for now without DT documentation files. It was tested in QEMU for Nokia N900. File /proc/cpuinfo contains correct Revision line from ATAG_REVISION and /proc/atags contains full ATAGs structure. Pali Rohár (5): arm: devtree: Set system_rev from DT /revision arm: boot: convert ATAG_REVISION to DT /revision entry arm: atags: Fix declaration of function save_atags arm: devtree: Read ATAGs structure from DT /chosen/linux,atags entry arm: boot: store ATAGs structure into DT /chosen/linux,atags entry arch/arm/boot/compressed/atags_to_fdt.c |8 ++- arch/arm/kernel/atags.h |4 ++-- arch/arm/kernel/devtree.c | 36 --- 3 files changed, 42 insertions(+), 6 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] arm: atags: Fix declaration of function save_atags
In file atags_proc.c function save_atags() expect const argument, but in
atags.h file is declarated as non const. Fix declaration in atags.h file to
match what is expected.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/kernel/atags.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/atags.h b/arch/arm/kernel/atags.h
index ec4164d..2dfc30f 100644
--- a/arch/arm/kernel/atags.h
+++ b/arch/arm/kernel/atags.h
@@ -1,7 +1,7 @@
#ifdef CONFIG_ATAGS_PROC
-extern void save_atags(struct tag *tags);
+extern void save_atags(const struct tag *tags);
#else
-static inline void save_atags(struct tag *tags) { }
+static inline void save_atags(const struct tag *tags) { }
#endif
void convert_to_tag_list(struct tag *tags);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] arm: boot: convert ATAG_REVISION to DT /revision entry
When uncompressing kernel image this patch convert ATAG_REVISION structure
into DT /revision entry. For legacy bootloaders which do not support DT
booting there is no other option how to pass ATAG_REVISION into kernel.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/boot/compressed/atags_to_fdt.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/compressed/atags_to_fdt.c
b/arch/arm/boot/compressed/atags_to_fdt.c
index 9448aa0..e7e1cc9 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int
total_space)
cpu_to_fdt32(atag-u.mem.size);
}
+ } else if (atag-hdr.tag == ATAG_REVISION) {
+ setprop_cell(fdt, /, revision,
atag-u.revision.rev);
} else if (atag-hdr.tag == ATAG_INITRD2) {
uint32_t initrd_start, initrd_size;
initrd_start = atag-u.initrd.start;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] arm: boot: store ATAGs structure into DT /chosen/linux,atags entry
Legacy bootloaders can pass additional information for kernel or legacy userspace applications. When booting DT kernel then ATAGs structure is not more visible after running kernel uncompress code. This patch stores full ATAGs structure into DT /chosen/linux,atags entry, so kernel can later reuse it and export via /proc/atags to userspace. Signed-off-by: Pali Rohár pali.ro...@gmail.com --- arch/arm/boot/compressed/atags_to_fdt.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c index e7e1cc9..ae93973 100644 --- a/arch/arm/boot/compressed/atags_to_fdt.c +++ b/arch/arm/boot/compressed/atags_to_fdt.c @@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) * address and size for each bank */ uint32_t mem_reg_property[2 * 2 * NR_BANKS]; int memcount = 0; - int ret, memsize; + int ret, memsize, atag_size; /* make sure we've got an aligned pointer */ if ((u32)atag_list 0x3) @@ -189,5 +189,9 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space) 4 * memcount * memsize); } + /* include the terminating ATAG_NONE */ + atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header); + setprop(fdt, /chosen, linux,atags, atag_list, atag_size); + return fdt_pack(fdt); } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] arm: devtree: Set system_rev from DT /revision
With this patch /revision DT entry is used to set global system_rev
variable. DT /revision is expected to be u32 numeric value.
TODO: add documentation
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/kernel/devtree.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..7d82749 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -19,6 +19,7 @@
#include linux/of_irq.h
#include linux/of_platform.h
#include linux/smp.h
+#include linux/libfdt_env.h
#include asm/cputype.h
#include asm/setup.h
@@ -26,6 +27,7 @@
#include asm/smp_plat.h
#include asm/mach/arch.h
#include asm/mach-types.h
+#include asm/system_info.h
#ifdef CONFIG_SMP
@@ -204,6 +206,8 @@ static const void * __init arch_get_next_mach(const char
*const **match)
const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
{
const struct machine_desc *mdesc, *mdesc_best = NULL;
+ unsigned long dt_root;
+ const u32 *rev;
#ifdef CONFIG_ARCH_MULTIPLATFORM
DT_MACHINE_START(GENERIC_DT, Generic DT based system)
@@ -215,17 +219,16 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
return NULL;
+ dt_root = of_get_flat_dt_root();
mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
if (!mdesc) {
const char *prop;
int size;
- unsigned long dt_root;
early_print(\nError: unrecognized/unsupported
device tree compatible list:\n[ );
- dt_root = of_get_flat_dt_root();
prop = of_get_flat_dt_prop(dt_root, compatible, size);
while (size 0) {
early_print('%s' , prop);
@@ -246,5 +249,10 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
/* Change machine number to match the mdesc we're using */
__machine_arch_type = mdesc-nr;
+ /* Set system revision from DT */
+ rev = of_get_flat_dt_prop(dt_root, revision, NULL);
+ if (rev)
+ system_rev = fdt32_to_cpu(*rev);
+
return mdesc;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] arm: devtree: Read ATAGs structure from DT /chosen/linux,atags entry
With this patch when linux kernel is compiled with ARM_ATAG_DTB_COMPAT it
reads ATAGs structure from /chosen/linux,atags entry and store it into
/proc/atags file. ATAGs structure is not parsed or evaluated, just kernel
exports it to userspace via procfs. It is needed for legacy userspace
application which expect some data from bootloader in /proc/atags file.
This patch keeps them running also on DT kernel if DT /chosen/linux,atags
entry exists.
TODO: add documentation
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/kernel/devtree.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 7d82749..69ff048 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -20,6 +20,7 @@
#include linux/of_platform.h
#include linux/smp.h
#include linux/libfdt_env.h
+#include linux/libfdt.h
#include asm/cputype.h
#include asm/setup.h
@@ -29,6 +30,7 @@
#include asm/mach-types.h
#include asm/system_info.h
+#include atags.h
#ifdef CONFIG_SMP
extern struct of_cpu_method __cpu_method_of_table[];
@@ -208,6 +210,11 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
const struct machine_desc *mdesc, *mdesc_best = NULL;
unsigned long dt_root;
const u32 *rev;
+ void *dt_virt;
+#ifdef CONFIG_ARM_ATAG_DTB_COMPAT
+ const void *atags;
+ unsigned long dt_chosen;
+#endif
#ifdef CONFIG_ARCH_MULTIPLATFORM
DT_MACHINE_START(GENERIC_DT, Generic DT based system)
@@ -216,7 +223,12 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
mdesc_best = __mach_desc_GENERIC_DT;
#endif
- if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
+ if (!dt_phys)
+ return NULL;
+
+ dt_virt = phys_to_virt(dt_phys);
+
+ if (!early_init_dt_verify(dt_virt))
return NULL;
dt_root = of_get_flat_dt_root();
@@ -254,5 +266,15 @@ const struct machine_desc * __init
setup_machine_fdt(unsigned int dt_phys)
if (rev)
system_rev = fdt32_to_cpu(*rev);
+#ifdef CONFIG_ARM_ATAG_DTB_COMPAT
+ /* Store DT /chosen/linux,atags into /proc/atags */
+ dt_chosen = fdt_path_offset(dt_virt, /chosen);
+ if (dt_chosen = 0) {
+ atags = of_get_flat_dt_prop(dt_chosen, linux,atags, NULL);
+ if (atags)
+ save_atags(atags);
+ }
+#endif
+
return mdesc;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Monday 06 July 2015 18:20:35 Pali Rohár wrote:
/chosen/linux,atags
This one. ATAGs are a Linux data struct.
Rob
Ok, and how read that property /chosen/linux,atags in function
setup_machine_fdt() from file arch/arm/kernel/devtree.c ?
of_get_flat_dt_prop() cannot be used unless somebody get me offset to
node /chosen...
Any idea?
fdt_path_offset() from libfdt.h seems to work...
Is solution like this one acceptable?
#include linux/libfdt.h
#include atags.h
... setup_machine_fdt(unsigned int dt_phys) {
dt_virt = phys_to_virt(dt_phys);
dt_chosen = fdt_path_offset(dt_virt, /chosen);
atags = of_get_flat_dt_prop(dt_chosen, linux,atags, NULL);
save_atags(atags);
}
(this is without checks for errors)
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Monday 06 July 2015 17:22:58 Rob Herring wrote: On Mon, Jul 6, 2015 at 8:12 AM, Pali Rohár pali.ro...@gmail.com wrote: On Monday 06 July 2015 14:31:27 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150706 05:25]: into which file should I put documentation about new DT properties? If it's Linux generic like linux,revision, then how about Documentation/devicetree/bindings/revision.txt? For the ATAGs, Documentation/devicetree/bindings/arm/atag.txt? Regards, Tony Hm... now I'm thinking into which DT field should I put atags and revision. In previous emails you wrote to use linux,atags, now arm,atags? And put them into root node? Or other? In arch/arm/boot/compressed/atags_to_fdt.c code I see that most atag properties are converted into /chosen node in DT... So what do you prefer for revision and what for atags? Some mentioned examples: /revision This one. This is a top level h/w property. /chosen/revision /linux,revision /chosen/linux,revision ... /atags /chosen/atags /linux,atags /chosen/linux,atags This one. ATAGs are a Linux data struct. Rob Ok, and how read that property /chosen/linux,atags in function setup_machine_fdt() from file arch/arm/kernel/devtree.c ? of_get_flat_dt_prop() cannot be used unless somebody get me offset to node /chosen... Any idea? /arm,atags /chosen/arm,atags ... -- Pali Rohár pali.ro...@gmail.com -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
rx51-battery.ko incompatiblity: board code vs DT
Hello, now I found out that rx51-battery.ko driver register sysnode /sys/class/power_supply/rx51-battery/ when booting with legacy board code. But when booting DT kernel it register sysnode with different name /sys/class/power_supply/n900-battery/ Sysfs node for DT kernel comes from Nokia N900 DTS file: arch/arm/boot/dts/omap3-n900.dts I would propose change which change DTS to rx51-battery to have it compatible with naming which is for legacy board code. It is just because to have compatibility and same naming scheme and also to make existing programs to work without needing patching them. What do you think? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: n900 in 4.2-rc0: repeating oopses
On Tuesday 30 June 2015 23:59:33 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150630 02:55]: I will try 4.2 at the end of week. At least today's 4.1.0-11549-g05a8256 boots just fine on my n900. Regards, Tony So, Pavel can you re-test? Maybe there can be problem with some driver which Tony did not compiled into zImage? Just speculation... -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: n900 in 4.2-rc0: repeating oopses
On Tuesday 30 June 2015 11:24:04 Pavel Machek wrote:
Hi!
Just tried booting 4.2-rc0 on n900 (commit
4a10a91756ef381bced7b88cfb9232f660b92d93) and it is broken. Previous
-rc0 version worked. This time, there's some output on console, but
too fast for me to read.
It seems oopses happen before mounting root. If you have serial
console, they should be easy to see.
I tried again according to pali's instructions, and it is still
broken the same way. Any other ideas? Does it work for you?
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 69a40cf..ff6f2bf 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -570,6 +570,7 @@
interrupts = 49;
dmas = sdma 69;
dma-names = rx;
+ status = disabled;
};
smartreflex_core: smartreflex@480cb000 {
Pavel
Ok, then it is not problem with omap crypto and HS device...
I will try 4.2 at the end of week.
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe 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: n900 in 4.2-rc0: repeating oopses
Hi! On Monday 29 June 2015 11:11:46 Pavel Machek wrote: Hi! Just tried booting 4.2-rc0 on n900 (commit 4a10a91756ef381bced7b88cfb9232f660b92d93) and it is broken. Previous -rc0 version worked. This time, there's some output on console, but too fast for me to read. What happen after errors are reported? Maybe you can enable RD mode and disable HW watchdogs to prevent device reboots... It seems oopses happen before mounting root. If you have serial console, they should be easy to see. I tried booting same kernel in qemu, but it seems to work ok there. Hm... Maybe problem with HS code? By chance, can you try to disable (omap) sham node in n900 DT file? (same way like omap aes is disabled) Any ideas? Thanks, Pavel -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Thursday 25 June 2015 00:22:05 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150625 00:21]: Ok, but what do you mean to forget any string conversion? No need for tohexstr() in the uncommpress code if the system_rev value is a number coming from the dts. Regards, Tony So /revision DT property will be (binary) value, right? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: [RESEND] [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
On Wednesday 24 June 2015 22:01:38 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150506 04:45]: On Wednesday 06 May 2015 13:04:01 Arnd Bergmann wrote: It needs to be done in this code, so system_rev variable is set properly... What I mean is which code accesses this variable that early? ATAG code is doing it at same early stage, so I added it to same early stage... Yes we should do this early like the other atags. Also, it seems strange to have a string property and then use kstrtouint to convert it into a number. I think it should either be specified in a DT binding to be a string and then have the kernel not assume that it is a number, or we should define it to be binary. Arnd Variable system_rev is number and it always was. So chaning type will break more parts. And it is string DT property to be human readable. Some other developers suggested for v2 to change it to string (from number). Both of them would be human readable, you just use something else to read them ;-) If we have a string here, we should just change all uses of system_rev in the kernel accordingly, there are only a few of them: Let's just keep it as a hex as it was. After all it's an existing interface in /proc that user space programs may expect to be in hex format already. Pali, care to repost the whole set again right after -rc1 with with rev property naming and documentation added? Just keep it as hex and let's forget any string conversion. Regards, Tony Ok, but what do you mean to forget any string conversion? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Friday 29 May 2015 00:24:13 Tony Lindgren wrote: * Matthijs van Duin matthijsvand...@gmail.com [150528 13:28]: On 28 May 2015 at 18:01, Tony Lindgren t...@atomide.com wrote: For failed device access you get an interrupt Well for failed reads you get a bus error, and catching those (e.g. using the existing exception mechanism used to catch MMU faults) is the whole issue. Though now that you mention it, it is true that for writes you won't get any fault (at least on the DM814x and AM335x the posting point appears to be the async bridge from MPUSS to the L3 interconnect) but an interconnect error irq instead. It may be easier to make some kind of harmless write (e.g. to the version register), wait a bit, and check if the write triggered an interconnect error. Feels hackish though: you'd need to be sure you waited long enough (though using a read from another device on the same L4 interconnect should be a reliable barrier in this case), and drivers for receiving/interpreting interconnect errors are not implemented yet on all SoCs (for some, like the AM335x, TI didn't even bother publishing the relevant data in its TRM). Interconnect errors can also be lost in some cases (multiple errors involving the same target in a short time window) though that problem shouldn't arise in this particular case. Hmm I believe the interrupt happens immediately trying to access an invalid device. But maybe I'm thinking about just errors if a device is not powered or clocked. So obviously some experiments need to be done :) The advantage here would be that the l3 driver actually already knows quite a bit about the devices on the bus. Also, presumably interconnect error reporting is unavailable on HS devices given the fact that all interconnect registers seemed to be inaccessible? Oh OK yeah then that would not work for Pali's case. I guess it just needs to be tested. Regards, Tony Ok, thanks for info. Do you have some quick small patches for testing? Or some pointers what is needed to modify and how? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: runtime check for omap-aes bus access permission (was: Re: 3.13-rc3 (commit 7ce93f3) breaks Nokia N900 DT boot)
On Wednesday 11 February 2015 14:40:33 Nishanth Menon wrote: On Wed, Feb 11, 2015 at 2:28 PM, Pali Rohár pali.ro...@gmail.com wrote: On Wednesday 11 February 2015 16:22:51 Matthijs van Duin wrote: On 11 February 2015 at 13:39, Pali Rohár pali.ro...@gmail.com wrote: Anyhow, since checking the firewalls/APs to see if you have permission will probably only get you yet another fault if things are walled off, the robust way of dealing with this sort of situation is by probing the device with a read while trapping bus faults. This also handles modules that are unreachable for other reasons, e.g. being disabled by eFuse. It is possible to patch kernel code to mask or ignore that fault? Can you help me with something like that? As I mentioned, I'm still learning my way around the kernel, so I don't feel very comfortable suggesting a concrete patch just yet. I've been browsing arch/arm/mm/ however and my impression is that all that would be required is editing fault.c by making a copy of do_bad but containing return user_mode(regs) || !fixup_exception(regs); and hook it onto the appropriate fault codes. However, this really needs the opinion of someone more familiar with this code. I do have an observation to make on the issue of fault decoding: the list in fsr-2level.c may be standard ARMv3 and ARMv4 aborts but they are quite wrong for ARMv7 which has: [ 0] - [ 1] alignment fault [ 2] debug event [ 3] section access flag fault [ 4] instruction cache maintainance fault (reported via data abort) [ 5] section translation fault [ 6] page access flag fault [ 7] page translation fault [ 8] bus error on access [ 9] section domain fault [10] - [11] page domain fault [12] bus error on section table walk [13] section permission fault [14] bus error on page table walk [15] page permission fault [16] (TLB conflict abort) [17] - [18] - [19] - [20] (lockdown abort) [21] - [22] async bus error (reported via data abort) [23] - [24] async parity/ECC error (reported via data abort) [25] parity/ECC error on access [26] (coprocessor abort) [27] - [28] parity/ECC error on section table walk [29] - [30] parity/ECC error on page table walk [31] - Some entries are patched up near the bottom of fault.c but many bogus messages remain, for example the on linefetch vs on non-linefetch is misleading since no such thing can be inferred from the fault status on v7. Also, the i-cache maintenance fault handling looks wrong to me: it should fetch the actual fault status from IFSR (even though the address still comes from DFSR) and dispatch based on that. Async external aborts (async bus error and async parity/ECC error) give you basically no info. DFAR will contain garbage hence displaying it will confuse rather than enlighten, a traceback is pointless since the instruction that caused the access is long retired, likewise user_mode() doesn't matter since a transition to kernel space may have happened after the access that cause the abort. Basically they should be treated more as an IRQ than as a fault (note they can also be masked just like irqs). In case of a bus error, it may be appropriate to just warn about it, or perhaps send a signal to the current process, although in the latter case it should have some means to distinguish it from a synchronous bus error. At least on the cortex-a8, a parity/ECC error (whether async or not) is to be regarded as absolutely fatal. Quoth the TRM: No recovery is possible. The abort handler must disable the caches, communicate the fail directly with the external system, request a reboot. Bit 10 no longer indicates an asynchronous (let alone imprecise) fault. Apart from the debug events and async aborts (and possibly some implementation-defined aborts), all aborts listed are synchronous, and DFAR/IFAR is valid. There's no technical obstruction to make these trappable via the kernel exception handling mechanism. (Though at least in case of parity/ECC errors one shouldn't.) Tony, Nishanth, or somebody else... can you help with memory management? Or do you know some expert for arch/arm/mm/ code? Folks in linux-arm-kernel are probably the right people, I suppose. Looping them in. So pinging linux-arm-kernel again. Any idea how to handle that fault? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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/10] ARM: OMAP3: Fix crypto support for HS devices
Hi Paul, this patch is also for omap2... Can you review it too? On Saturday 28 February 2015 17:24:36 Pavel Machek wrote: On Thu 2015-02-26 14:49:52, Pali Rohár wrote: Register crypto hwmod links only if they are not disabled in DT. If DT information is missing, enable them only for GP devices. Before this patch crypto hwmod links were always disabled for all HS devices and it was not possible to use omap-aes and omap-sham linux drivers. Signed-off-by: Pali Rohár pali.ro...@gmail.com Acked-by: Pavel Machek pa...@ucw.cz -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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 01/10] ARM: OMAP2+: Return correct error values from device and hwmod
On Thursday 26 February 2015 14:49:51 Pali Rohár wrote:
Without this patch function pm_runtime_get_sync() returns 0 even when some
omap subfunction fails. This patch properly propagate error codes from omap
functions back to caller.
This patch fix problem, when loading omap-aes driver in qemu cause kernel
oops.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
arch/arm/mach-omap2/omap_device.c | 30 +-
arch/arm/mach-omap2/omap_hwmod.c | 10 ++
2 files changed, 23 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index be9541e..9fd47a9 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -224,13 +224,13 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
*/
static int _omap_device_enable_hwmods(struct omap_device *od)
{
+ int ret = 0;
int i;
for (i = 0; i od-hwmods_cnt; i++)
- omap_hwmod_enable(od-hwmods[i]);
+ ret |= omap_hwmod_enable(od-hwmods[i]);
- /* XXX pass along return value here? */
- return 0;
+ return ret;
}
/**
@@ -241,13 +241,13 @@ static int _omap_device_enable_hwmods(struct
omap_device *od)
*/
static int _omap_device_idle_hwmods(struct omap_device *od)
{
+ int ret = 0;
int i;
for (i = 0; i od-hwmods_cnt; i++)
- omap_hwmod_idle(od-hwmods[i]);
+ ret |= omap_hwmod_idle(od-hwmods[i]);
- /* XXX pass along return value here? */
- return 0;
+ return ret;
}
/* Public functions for use by core code */
@@ -595,18 +595,20 @@ static int _od_runtime_suspend(struct device *dev)
int ret;
ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
- if (!ret)
- omap_device_idle(pdev);
-
- return ret;
+ return omap_device_idle(pdev);
}
static int _od_runtime_resume(struct device *dev)
{
struct platform_device *pdev = to_platform_device(dev);
+ int ret;
- omap_device_enable(pdev);
+ ret = omap_device_enable(pdev);
+ if (ret)
+ return ret;
return pm_generic_runtime_resume(dev);
}
@@ -740,7 +742,8 @@ int omap_device_enable(struct platform_device *pdev)
ret = _omap_device_enable_hwmods(od);
- od-_state = OMAP_DEVICE_STATE_ENABLED;
+ if (ret == 0)
+ od-_state = OMAP_DEVICE_STATE_ENABLED;
return ret;
}
@@ -770,7 +773,8 @@ int omap_device_idle(struct platform_device *pdev)
ret = _omap_device_idle_hwmods(od);
- od-_state = OMAP_DEVICE_STATE_IDLE;
+ if (ret == 0)
+ od-_state = OMAP_DEVICE_STATE_IDLE;
return ret;
}
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index 92afb72..870e984 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3350,16 +3350,17 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
*/
int omap_hwmod_idle(struct omap_hwmod *oh)
{
+ int r;
unsigned long flags;
if (!oh)
return -EINVAL;
spin_lock_irqsave(oh-_lock, flags);
- _idle(oh);
+ r = _idle(oh);
spin_unlock_irqrestore(oh-_lock, flags);
- return 0;
+ return r;
}
/**
@@ -3372,16 +3373,17 @@ int omap_hwmod_idle(struct omap_hwmod *oh)
*/
int omap_hwmod_shutdown(struct omap_hwmod *oh)
{
+ int r;
unsigned long flags;
if (!oh)
return -EINVAL;
spin_lock_irqsave(oh-_lock, flags);
- _shutdown(oh);
+ r = _shutdown(oh);
spin_unlock_irqrestore(oh-_lock, flags);
- return 0;
+ return r;
}
/*
Hello Paul, can you apply this patch?
--
Pali Rohár
pali.ro...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe 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: [PATCHv7] media: i2c/adp1653: fix includes
On Thursday 09 April 2015 14:43:59 Javier Martinez Canillas wrote: Hello Pavel, diff --git a/drivers/media/i2c/adp1653.c b/drivers/media/i2c/adp1653.c index d703636..7107ac2 100644 --- a/drivers/media/i2c/adp1653.c +++ b/drivers/media/i2c/adp1653.c @@ -35,8 +35,8 @@ #include linux/module.h #include linux/i2c.h #include linux/slab.h -#include linux/of_gpio.h -#include linux/gpio.h +#include linux/of.h +#include linux/gpio/consumer.h #include media/adp1653.h #include media/v4l2-device.h Please re-spin your previous patch and submit it properly. Best regards, Javier Hi all! What about stopping this meaningless discussion about resending full patch series when everybody know how to fix is quickly in editor (e.g with sed under 5s) and not wasting another 10 minutes to generate new unified diff sent via SMTP protocol? -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line unsubscribe 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: ARM errata 430973 on multi platform kernels (was: OMAP3-N900: Add microphone bias voltages)
On Sunday 05 April 2015 15:00:45 Sebastian Reichel wrote: On Fri, Apr 03, 2015 at 02:21:48PM -0500, Robert Nelson wrote: And yes, for armhf userland one gets random oopses at least on the Nokia N900. AFAIK this is not true for all ARMv7 processors (especially non omaps), though. http://www.spinics.net/lists/linux-omap/msg108511.html See also 5c86c5339c56 (ARM: omap2plus_defconfig: Enable ARM erratum 430973 for omap3). For me the random oopses occur without this config flag and are fixed by it. The workaround is not very suitable for multi platform kernels, though, since its enabled also for unaffected platforms. As far as I can see the CONFIG_ARM_ERRATA_430973 flag is checked in proc-v7.S and in proc-v7-2level.S. I think the first file is irrelevant, since it can be fixed later (see workaround in nokia_n900_legacy_init in pdata-quirks.c). Yes so it seems, and the bootloaders should really set it. It's also disabled for multiplatform builds. These are now done in u-boot as of: v2015.04-rc4 http://git.denx.de/?p=u-boot.git;a=commit;h=c6f90e1418a84fe5 fa463b38403bd1845cb6a59c Seems like include/configs/nokia_rx51.h has been forgotten. Note, that the kernel must still be able to enable the bit itself (in case NOLO is used without u-boot). -- Sebastian You must not expect that bootloader set something. Nokia N900 has closed and signed bootloader which cannot be easily replaced and or fixed. For N900 there is U-Boot but it does not support lot of things (load kernel via usb or serial) so for developers it is better to use original Nokia bootloader. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: ARM errata 430973 on multi platform kernels (was: OMAP3-N900: Add microphone bias voltages)
On Sunday 05 April 2015 15:45:28 Sebastian Reichel wrote: Hi, On Sun, Apr 05, 2015 at 03:26:14PM +0200, Pali Rohár wrote: Yes so it seems, and the bootloaders should really set it. It's also disabled for multiplatform builds. These are now done in u-boot as of: v2015.04-rc4 http://git.denx.de/?p=u-boot.git;a=commit;h=c6f90e1418a8 4fe5 fa463b38403bd1845cb6a59c Seems like include/configs/nokia_rx51.h has been forgotten. Note, that the kernel must still be able to enable the bit itself (in case NOLO is used without u-boot). You must not expect that bootloader set something. Nokia N900 has closed and signed bootloader which cannot be easily replaced and or fixed. For N900 there is U-Boot but it does not support lot of things (load kernel via usb or serial) so for developers it is better to use original Nokia bootloader. Yes, I'm aware of that. I think having the IBE bit set in u-boot has advantages nevertheless. I think the kernel can't enable the bit sufficiently early if its compiled in thumb-mode itself (CONFIG_THUMB2_KERNEL). So I suggest to enable the IBE bit in the kernel (that part is already done) *and* in u-boot. -- Sebastian Yes. Code for both (U-Boot and linux kernel) exists and are already included. In linux kernel code is since 3.14-rc6 and in U-Boot code is there since beginning of Nokia N900 support (2013.04) directly in board code. I believe that you guys do not remove or break that code :-) Nokia N900 needs slightly different code for setting IBE bit as other omap3 boards. For info is in commit message of commit 4748a7240284b0f68bd47a66365c2cd561939830. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data
On Monday 16 March 2015 16:29:39 Tony Lindgren wrote: I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali. No. In DT boot there is missing /proc/atags file (readable by userspace processes). And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data
On Monday 16 March 2015 22:01:43 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [150316 13:59]: On Monday 16 March 2015 16:29:39 Tony Lindgren wrote: I believe the last pending issues is the support for ATAG_REVISION in device tree mode as posted by Pali. No. In DT boot there is missing /proc/atags file (readable by userspace processes). Oh OK thanks for the update. And also broken AES/SHA/MD5 support. Fix for crypto DT stuff I already sent. But this is not a regression in mainline with legacy boot vs device tree based booting, right? Sounds like it never worked in the mainline or am thinking of some other set of patches? Regards, Tony In legacy board code are DMA channels defined. In DT files not. So I think this is regression. Omap secure devices are broken in both legacy DT code, but non secure could work with legacy code. But all devices booted with DT are broken. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 00/10] omap3 crypto fixes
On Sunday 08 March 2015 17:35:13 Paul Walmsley wrote: On Sun, 8 Mar 2015, Pali Rohár wrote: On Friday 06 March 2015 23:23:06 Aaro Koskinen wrote: On Fri, Mar 06, 2015 at 10:36:32AM -0800, Tony Lindgren wrote: Are there any fixes in this series that should go into v4.0-rc series, or can it all wait for v4.1? I think these all should wait for v4.1. A. I would suggest to include at least patches 01, 04, 06. Probably those could go to -stable tree... but this decision is up to you. I'm not sure patch 1 is a fix. As far as I know we haven't run into any issues with it on real hardware - only on QEMU - unless you know otherwise, Pali? Are we sure that the QEMU model behavior matches the hardware? - Paul Patch 1 check for return value of more functions. If real HW or software emulated HW (in qemu) does not support e.g. aes then kernel show oops message, because kernel does not check return values and try to touch non-existent HW. So I think patch 1 is really fix. In my opinion if something can fail, then kernel should check if it failed. And not expect that function call always pass. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
[PATCH v2] crypto: omap-sham: Check for return value from pm_runtime_get_sync
Function pm_runtime_get_sync could fail and we need to check return
value to prevent kernel crash.
Signed-off-by: Pali Rohár pali.ro...@gmail.com
---
v2: Check return value for all pm_runtime_get_sync() calls
---
drivers/crypto/omap-sham.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index b20e374..c5df53d 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -362,7 +362,13 @@ static void omap_sham_copy_ready_hash(struct ahash_request
*req)
static int omap_sham_hw_init(struct omap_sham_dev *dd)
{
- pm_runtime_get_sync(dd-dev);
+ int err;
+
+ err = pm_runtime_get_sync(dd-dev);
+ if (err 0) {
+ dev_err(dd-dev, failed to get sync: %d\n, err);
+ return err;
+ }
if (!test_bit(FLAGS_INIT, dd-flags)) {
set_bit(FLAGS_INIT, dd-flags);
@@ -1949,7 +1955,13 @@ static int omap_sham_probe(struct platform_device *pdev)
dd-flags |= dd-pdata-flags;
pm_runtime_enable(dev);
- pm_runtime_get_sync(dev);
+
+ err = pm_runtime_get_sync(dev);
+ if (err 0) {
+ dev_err(dev, failed to get sync: %d\n, err);
+ goto err_pm;
+ }
+
rev = omap_sham_read(dd, SHA_REG_REV(dd));
pm_runtime_put_sync(pdev-dev);
@@ -1979,6 +1991,7 @@ err_algs:
for (j = dd-pdata-algs_info[i].registered - 1; j = 0; j--)
crypto_unregister_ahash(
dd-pdata-algs_info[i].algs_list[j]);
+err_pm:
pm_runtime_disable(dev);
if (dd-dma_lch)
dma_release_channel(dd-dma_lch);
@@ -2021,7 +2034,11 @@ static int omap_sham_suspend(struct device *dev)
static int omap_sham_resume(struct device *dev)
{
- pm_runtime_get_sync(dev);
+ int err = pm_runtime_get_sync(dev);
+ if (err 0) {
+ dev_err(dev, failed to get sync: %d\n, err);
+ return err;
+ }
return 0;
}
#endif
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
