Re: n900 in next-20170901

* Joonsoo Kim [171115 02:44]: > On Tue, Nov 14, 2017 at 06:04:00PM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171115 00:48]: > > > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim

Re: n900 in next-20170901

* Joonsoo Kim [171115 02:44]: > On Tue, Nov 14, 2017 at 06:04:00PM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171115 00:48]: > > > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim [171114 06:34]: > > > > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony

Re: n900 in next-20170901

On Tue, Nov 14, 2017 at 06:04:00PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171115 00:48]: > > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171114 06:34]: > > > > On Fri, Nov 10, 2017 at 07:36:20AM -0800,

Re: n900 in next-20170901

On Tue, Nov 14, 2017 at 06:04:00PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171115 00:48]: > > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171114 06:34]: > > > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > > > > * Joonsoo Kim

Re: n900 in next-20170901

* Joonsoo Kim [171115 00:48]: > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171114 06:34]: > > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim

Re: n900 in next-20170901

* Joonsoo Kim [171115 00:48]: > On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171114 06:34]: > > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim [171110 06:34]: > > > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony

Re: n900 in next-20170901

On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171114 06:34]: > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171110 06:34]: > > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800,

Re: n900 in next-20170901

On Tue, Nov 14, 2017 at 09:37:19AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171114 06:34]: > > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171110 06:34]: > > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > > +#define

Re: n900 in next-20170901

* Tero Kristo [171114 20:03]: > On 14/11/17 21:44, Tony Lindgren wrote: > > * Tero Kristo [171114 19:34]: > > > I guess you could just use rx51_secure_dispatcher and ditch the > > > save_secure_ram_context call completely (and most of the other related > > >

Re: n900 in next-20170901

* Tero Kristo [171114 20:03]: > On 14/11/17 21:44, Tony Lindgren wrote: > > * Tero Kristo [171114 19:34]: > > > I guess you could just use rx51_secure_dispatcher and ditch the > > > save_secure_ram_context call completely (and most of the other related > > > code)? That one would handle the

Re: n900 in next-20170901

On 14/11/17 21:44, Tony Lindgren wrote: * Tero Kristo [171114 19:34]: I guess you could just use rx51_secure_dispatcher and ditch the save_secure_ram_context call completely (and most of the other related code)? That one would handle the cache also in a clean manner.

Re: n900 in next-20170901

On 14/11/17 21:44, Tony Lindgren wrote: * Tero Kristo [171114 19:34]: I guess you could just use rx51_secure_dispatcher and ditch the save_secure_ram_context call completely (and most of the other related code)? That one would handle the cache also in a clean manner. Something like:

Re: n900 in next-20170901

* Tero Kristo [171114 19:34]: > I guess you could just use rx51_secure_dispatcher and ditch the > save_secure_ram_context call completely (and most of the other related > code)? That one would handle the cache also in a clean manner. > > Something like: > >

Re: n900 in next-20170901

* Tero Kristo [171114 19:34]: > I guess you could just use rx51_secure_dispatcher and ditch the > save_secure_ram_context call completely (and most of the other related > code)? That one would handle the cache also in a clean manner. > > Something like: > > rx51_secure_dispatcher(25, 0,

Re: n900 in next-20170901

On 14/11/17 19:37, Tony Lindgren wrote: * Joonsoo Kim [171114 06:34]: On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: * Joonsoo Kim [171110 06:34]: On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: +#define

Re: n900 in next-20170901

On 14/11/17 19:37, Tony Lindgren wrote: * Joonsoo Kim [171114 06:34]: On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: * Joonsoo Kim [171110 06:34]: On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: +#define OMAP34XX_SRAM_PHYS 0x4020 +#define

Re: n900 in next-20170901

* Joonsoo Kim [171114 06:34]: > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171110 06:34]: > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > +#define OMAP34XX_SRAM_PHYS 0x4020

Re: n900 in next-20170901

* Joonsoo Kim [171114 06:34]: > On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171110 06:34]: > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > > +#define OMAP34XX_SRAM_VIRT

Re: n900 in next-20170901

On Mon, Nov 13, 2017 at 01:15:30PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171110 07:36]: > > * Joonsoo Kim [171110 06:34]: > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > >

Re: n900 in next-20170901

On Mon, Nov 13, 2017 at 01:15:30PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171110 07:36]: > > * Joonsoo Kim [171110 06:34]: > > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > > +#define OMAP34XX_SRAM_VIRT

Re: n900 in next-20170901

On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171110 06:34]: > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > >

Re: n900 in next-20170901

On Fri, Nov 10, 2017 at 07:36:20AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171110 06:34]: > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > > +#define OMAP34XX_SRAM_SIZE

Re: n900 in next-20170901

* Tony Lindgren [171110 07:36]: > * Joonsoo Kim [171110 06:34]: > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > > +#define

Re: n900 in next-20170901

* Tony Lindgren [171110 07:36]: > * Joonsoo Kim [171110 06:34]: > > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > > +#define OMAP34XX_SRAM_SIZE 0x1 > > > > For my

Re: n900 in next-20170901

* Joonsoo Kim [171110 06:43]: > On Thu, Nov 09, 2017 at 10:23:40PM -0800, Tony Lindgren wrote: > > * Tony Lindgren [171109 22:19]: > > > * Tony Lindgren [171110 03:28]: > > > > Then I'll follow up on cleaning up save_secure_ram_context

Re: n900 in next-20170901

* Joonsoo Kim [171110 06:43]: > On Thu, Nov 09, 2017 at 10:23:40PM -0800, Tony Lindgren wrote: > > * Tony Lindgren [171109 22:19]: > > > * Tony Lindgren [171110 03:28]: > > > > Then I'll follow up on cleaning up save_secure_ram_context later. > > > > > > Here's a better version, the static

Re: n900 in next-20170901

* Joonsoo Kim [171110 06:34]: > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > +#define OMAP34XX_SRAM_SIZE 0x1 > > For my testing environment, vmalloc address

Re: n900 in next-20170901

* Joonsoo Kim [171110 06:34]: > On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > > +#define OMAP34XX_SRAM_PHYS 0x4020 > > +#define OMAP34XX_SRAM_VIRT 0xd001 > > +#define OMAP34XX_SRAM_SIZE 0x1 > > For my testing environment, vmalloc address space is started at >

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 10:23:40PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171109 22:19]: > > * Tony Lindgren [171110 03:28]: > > > Then I'll follow up on cleaning up save_secure_ram_context later. > > > > Here's a better version, the static mapping

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 10:23:40PM -0800, Tony Lindgren wrote: > * Tony Lindgren [171109 22:19]: > > * Tony Lindgren [171110 03:28]: > > > Then I'll follow up on cleaning up save_secure_ram_context later. > > > > Here's a better version, the static mapping did not get used.. It > > just moved

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171110 00:10]: > > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > > Hmm OK. Does your first patch above now have the initcall issue too? > > > It boots if I make that also

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 07:26:10PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171110 00:10]: > > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > > Hmm OK. Does your first patch above now have the initcall issue too? > > > It boots if I make that also subsys_initcall and then

Re: n900 in next-20170901

* Tony Lindgren [171109 22:19]: > * Tony Lindgren [171110 03:28]: > > Then I'll follow up on cleaning up save_secure_ram_context later. > > Here's a better version, the static mapping did not get used.. It > just moved the area so it happened to work. It

Re: n900 in next-20170901

* Tony Lindgren [171109 22:19]: > * Tony Lindgren [171110 03:28]: > > Then I'll follow up on cleaning up save_secure_ram_context later. > > Here's a better version, the static mapping did not get used.. It > just moved the area so it happened to work. It needs to be set > up as

Re: n900 in next-20170901

* Tony Lindgren [171110 03:28]: > * Joonsoo Kim [171110 00:10]: > > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > > Hmm OK. Does your first patch above now have the initcall issue too? > > > It boots if I make that also

Re: n900 in next-20170901

* Tony Lindgren [171110 03:28]: > * Joonsoo Kim [171110 00:10]: > > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > > Hmm OK. Does your first patch above now have the initcall issue too? > > > It boots if I make that also subsys_initcall and then I get: > > > > > [

Re: n900 in next-20170901

* Joonsoo Kim [171110 00:10]: > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > Hmm OK. Does your first patch above now have the initcall issue too? > > It boots if I make that also subsys_initcall and then I get: > > > [2.078094] vmalloc_pool_init:

Re: n900 in next-20170901

* Joonsoo Kim [171110 00:10]: > On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > > Hmm OK. Does your first patch above now have the initcall issue too? > > It boots if I make that also subsys_initcall and then I get: > > > [2.078094] vmalloc_pool_init: DMA: get vmalloc area:

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171109 03:47]: > > Could you test following two commits on my updated branch? > > > > "arm/dma: vmalloc area allocation" > > Won't boot at this commit: > > [6.747283] save_secure_sram()

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 07:08:54AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171109 03:47]: > > Could you test following two commits on my updated branch? > > > > "arm/dma: vmalloc area allocation" > > Won't boot at this commit: > > [6.747283] save_secure_sram() returns ff02 > [

Re: n900 in next-20170901

* Joonsoo Kim [171109 03:47]: > Could you test following two commits on my updated branch? > > "arm/dma: vmalloc area allocation" Won't boot at this commit: [6.747283] save_secure_sram() returns ff02 [6.751983] save_secure_sram()'s param: 0: 0x4 [

Re: n900 in next-20170901

* Joonsoo Kim [171109 03:47]: > Could you test following two commits on my updated branch? > > "arm/dma: vmalloc area allocation" Won't boot at this commit: [6.747283] save_secure_sram() returns ff02 [6.751983] save_secure_sram()'s param: 0: 0x4 [6.756561] save_secure_sram()'s

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 09:36:39AM +0900, Joonsoo Kim wrote: > On Wed, Nov 08, 2017 at 04:11:13PM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171109 00:05]: > > > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim

Re: n900 in next-20170901

On Thu, Nov 09, 2017 at 09:36:39AM +0900, Joonsoo Kim wrote: > On Wed, Nov 08, 2017 at 04:11:13PM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171109 00:05]: > > > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > > > * Joonsoo Kim [171108 07:43]: > > > > > On Tue, Nov 07,

Re: n900 in next-20170901

On Wed, Nov 08, 2017 at 04:11:13PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171109 00:05]: > > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171108 07:43]: > > > > On Tue, Nov 07, 2017 at 07:48:42AM -0800,

Re: n900 in next-20170901

On Wed, Nov 08, 2017 at 04:11:13PM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171109 00:05]: > > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > > * Joonsoo Kim [171108 07:43]: > > > > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > > > > So it seems the

Re: n900 in next-20170901

* Joonsoo Kim [171109 00:05]: > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171108 07:43]: > > > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > > > So it seems the issue is currently at the

Re: n900 in next-20170901

* Joonsoo Kim [171109 00:05]: > On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > > * Joonsoo Kim [171108 07:43]: > > > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > > > So it seems the issue is currently at the atomic_pool_init() > > > > related code? > > >

Re: n900 in next-20170901

On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171108 07:43]: > > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > > So it seems the issue is currently at the atomic_pool_init() > > > related code? > > > > Yes, your test

Re: n900 in next-20170901

On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote: > * Joonsoo Kim [171108 07:43]: > > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > > So it seems the issue is currently at the atomic_pool_init() > > > related code? > > > > Yes, your test showed it although I

Re: n900 in next-20170901

* Joonsoo Kim [171108 07:43]: > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > So it seems the issue is currently at the atomic_pool_init() > > related code? > > Yes, your test showed it although I can't find any clue in > atomic_pool_init(). > >

Re: n900 in next-20170901

* Joonsoo Kim [171108 07:43]: > On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > > So it seems the issue is currently at the atomic_pool_init() > > related code? > > Yes, your test showed it although I can't find any clue in > atomic_pool_init(). > > Could you test updated

Re: n900 in next-20170901

On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > Hi, > > * Joonsoo Kim [171107 05:30]: > > Could you test follwing updated branch? > > > > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901 > > > > It has three relevant commits on top and

Re: n900 in next-20170901

On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote: > Hi, > > * Joonsoo Kim [171107 05:30]: > > Could you test follwing updated branch? > > > > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901 > > > > It has three relevant commits on top and enables CMA memory use.

Re: n900 in next-20170901

Hi, * Joonsoo Kim [171107 05:30]: > Could you test follwing updated branch? > > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901 > > It has three relevant commits on top and enables CMA memory use. Okie dokie. > "arm/dma: remove i-cache flush" Your

Re: n900 in next-20170901

Hi, * Joonsoo Kim [171107 05:30]: > Could you test follwing updated branch? > > https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901 > > It has three relevant commits on top and enables CMA memory use. Okie dokie. > "arm/dma: remove i-cache flush" Your branch at the above

Re: n900 in next-20170901

Hello, Sorry for dealy. I was on vacation during last week. On Thu, Oct 26, 2017 at 07:16:27AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171025 21:45]: > > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > > > Great, this branch boots on n900! Early

Re: n900 in next-20170901

Hello, Sorry for dealy. I was on vacation during last week. On Thu, Oct 26, 2017 at 07:16:27AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171025 21:45]: > > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > > > Great, this branch boots on n900! Early parts of the dmesg attached

Re: n900 in next-20170901

* Joonsoo Kim [171025 21:45]: > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > > Great, this branch boots on n900! Early parts of the dmesg attached > > below. > > Sound good. Perhaps, problem is due to the cache management. With my > patchset, direct

Re: n900 in next-20170901

* Joonsoo Kim [171025 21:45]: > On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > > Great, this branch boots on n900! Early parts of the dmesg attached > > below. > > Sound good. Perhaps, problem is due to the cache management. With my > patchset, direct mapping for CMA area is

Re: n900 in next-20170901

On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171022 21:51]: > > On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [171019 18:53]: > > > > Oops... I made a mistak. Could you test

Re: n900 in next-20170901

On Wed, Oct 25, 2017 at 10:31:38AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171022 21:51]: > > On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [171019 18:53]: > > > > Oops... I made a mistak. Could you test with reverting commit > > > >

Re: n900 in next-20170901

* Joonsoo Kim [171022 21:51]: > On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [171019 18:53]: > > > Oops... I made a mistak. Could you test with reverting commit > > > c977ee2803787363187d6aca9cebdabc793c6531

Re: n900 in next-20170901

* Joonsoo Kim [171022 21:51]: > On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [171019 18:53]: > > > Oops... I made a mistak. Could you test with reverting commit > > > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call > > >

Re: n900 in next-20170901

On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171019 18:53]: > > Oops... I made a mistak. Could you test with reverting commit > > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call > > save_secure_ram_context() for test") in

Re: n900 in next-20170901

On Fri, Oct 20, 2017 at 10:31:47AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171019 18:53]: > > Oops... I made a mistak. Could you test with reverting commit > > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call > > save_secure_ram_context() for test") in that branch? > > Without

Re: n900 in next-20170901

* Joonsoo Kim [171019 18:53]: > Oops... I made a mistak. Could you test with reverting commit > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call > save_secure_ram_context() for test") in that branch? > Without reverting it, it doesn't call 'smc' so it always

Re: n900 in next-20170901

* Joonsoo Kim [171019 18:53]: > Oops... I made a mistak. Could you test with reverting commit > c977ee2803787363187d6aca9cebdabc793c6531 ("omap: forcibly call > save_secure_ram_context() for test") in that branch? > Without reverting it, it doesn't call 'smc' so it always cause a > hang. Oops I

Re: n900 in next-20170901

On Thu, Oct 19, 2017 at 11:30:34AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171018 01:27]: > > On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [170925 01:06]: > > > > On Thu, Sep 21, 2017 at 10:28:11AM -0700,

Re: n900 in next-20170901

On Thu, Oct 19, 2017 at 11:30:34AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [171018 01:27]: > > On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [170925 01:06]: > > > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > > > > * Joonsoo Kim

Re: n900 in next-20170901

* Joonsoo Kim [171018 01:27]: > On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [170925 01:06]: > > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > > > * Joonsoo Kim

Re: n900 in next-20170901

* Joonsoo Kim [171018 01:27]: > On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [170925 01:06]: > > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > > > * Joonsoo Kim [170914 23:55]: > > > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony

Re: n900 in next-20170901

On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170925 01:06]: > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [170914 23:55]: > > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700,

Re: n900 in next-20170901

On Mon, Sep 25, 2017 at 07:54:37AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170925 01:06]: > > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > > * Joonsoo Kim [170914 23:55]: > > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > > > > Yes I disabled

Re: n900 in next-20170901

* Joonsoo Kim [170925 01:06]: > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [170914 23:55]: > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > > > Yes I disabled CONFIG_HIGHMEM and n900

Re: n900 in next-20170901

* Joonsoo Kim [170925 01:06]: > On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > > * Joonsoo Kim [170914 23:55]: > > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it, > > > > you need to remove it

Re: n900 in next-20170901

On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170914 23:55]: > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it, > > > you need to remove it from

Re: n900 in next-20170901

On Thu, Sep 21, 2017 at 10:28:11AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170914 23:55]: > > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it, > > > you need to remove it from arch/arm/mach-omap2/Kconfig that >

Re: n900 in next-20170901

* Joonsoo Kim [170914 23:55]: > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it, > > you need to remove it from arch/arm/mach-omap2/Kconfig that > > selects it if ARCH_OMAP2PLUS_TYPICAL is

Re: n900 in next-20170901

* Joonsoo Kim [170914 23:55]: > On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > > Yes I disabled CONFIG_HIGHMEM and n900 boots. To disable it, > > you need to remove it from arch/arm/mach-omap2/Kconfig that > > selects it if ARCH_OMAP2PLUS_TYPICAL is selected. > > Okay. Problem

Re: Linux-next broken for 2 weeks was Re: n900 in next-20170901

On Tue 2017-09-19 08:00:10, Stephen Rothwell wrote: > Hi Pavel, > > On Mon, 18 Sep 2017 10:11:09 +0200 Pavel Machek wrote: > > > > Unfortunately, rest of the world can reproduce the error, and it means > > linux-next is useless for us. > > > > I'd expect you to drop the relevant

Re: Linux-next broken for 2 weeks was Re: n900 in next-20170901

On Tue 2017-09-19 08:00:10, Stephen Rothwell wrote: > Hi Pavel, > > On Mon, 18 Sep 2017 10:11:09 +0200 Pavel Machek wrote: > > > > Unfortunately, rest of the world can reproduce the error, and it means > > linux-next is useless for us. > > > > I'd expect you to drop the relevant tree from

Re: Linux-next broken for 2 weeks was Re: n900 in next-20170901

Hi Pavel, On Mon, 18 Sep 2017 10:11:09 +0200 Pavel Machek wrote: > > Unfortunately, rest of the world can reproduce the error, and it means > linux-next is useless for us. > > I'd expect you to drop the relevant tree from linux-next when the > error was reported. Clearly, those

Re: Linux-next broken for 2 weeks was Re: n900 in next-20170901

Hi Pavel, On Mon, 18 Sep 2017 10:11:09 +0200 Pavel Machek wrote: > > Unfortunately, rest of the world can reproduce the error, and it means > linux-next is useless for us. > > I'd expect you to drop the relevant tree from linux-next when the > error was reported. Clearly, those patches are

Linux-next broken for 2 weeks was Re: n900 in next-20170901

Hi! > > > > After commit 9caf25f996e8, user for CMA memory should use to check > > > > PageHighmem in order to get proper virtual address of the page. If > > > > someone doesn't use it, it is possible to use wrong virtual address > > > > and it then causes the use of wrong physical address. > > >

Linux-next broken for 2 weeks was Re: n900 in next-20170901

Hi! > > > > After commit 9caf25f996e8, user for CMA memory should use to check > > > > PageHighmem in order to get proper virtual address of the page. If > > > > someone doesn't use it, it is possible to use wrong virtual address > > > > and it then causes the use of wrong physical address. > > >

Re: n900 in next-20170901

Hello, On Fri, Sep 15, 2017 at 03:28:44PM +0200, Pali Rohár wrote: > On Thursday 07 September 2017 16:30:38 Joonsoo Kim wrote: > > If it doesn't help, is there a way to test n900 configuration in QEMU? > > Hi Joonsoo, linaro version of QEMU has support for n900 machine. For > more information

Re: n900 in next-20170901

Hello, On Fri, Sep 15, 2017 at 03:28:44PM +0200, Pali Rohár wrote: > On Thursday 07 September 2017 16:30:38 Joonsoo Kim wrote: > > If it doesn't help, is there a way to test n900 configuration in QEMU? > > Hi Joonsoo, linaro version of QEMU has support for n900 machine. For > more information

Re: n900 in next-20170901

On Fri, Sep 15, 2017 at 03:18:18PM +0200, Pavel Machek wrote: > Hi! > > > > After commit 9caf25f996e8, user for CMA memory should use to check > > > PageHighmem in order to get proper virtual address of the page. If > > > someone doesn't use it, it is possible to use wrong virtual address > > >

Re: n900 in next-20170901

On Fri, Sep 15, 2017 at 03:18:18PM +0200, Pavel Machek wrote: > Hi! > > > > After commit 9caf25f996e8, user for CMA memory should use to check > > > PageHighmem in order to get proper virtual address of the page. If > > > someone doesn't use it, it is possible to use wrong virtual address > > >

Re: n900 in next-20170901

On Thursday 07 September 2017 16:30:38 Joonsoo Kim wrote: > If it doesn't help, is there a way to test n900 configuration in QEMU? Hi Joonsoo, linaro version of QEMU has support for n900 machine. For more information how to prepare & run kernel image see this email:

Re: n900 in next-20170901

On Thursday 07 September 2017 16:30:38 Joonsoo Kim wrote: > If it doesn't help, is there a way to test n900 configuration in QEMU? Hi Joonsoo, linaro version of QEMU has support for n900 machine. For more information how to prepare & run kernel image see this email:

Re: n900 in next-20170901

Hi! > > After commit 9caf25f996e8, user for CMA memory should use to check > > PageHighmem in order to get proper virtual address of the page. If > > someone doesn't use it, it is possible to use wrong virtual address > > and it then causes the use of wrong physical address. > >

Re: n900 in next-20170901

Hi! > > After commit 9caf25f996e8, user for CMA memory should use to check > > PageHighmem in order to get proper virtual address of the page. If > > someone doesn't use it, it is possible to use wrong virtual address > > and it then causes the use of wrong physical address. > >

Re: n900 in next-20170901

On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170913 00:54]: > > On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > > > I doubt that QEMU n900 boots in secure mode but instead shows > > > the SoC as general purpose SoC. If

Re: n900 in next-20170901

On Wed, Sep 13, 2017 at 09:31:27AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170913 00:54]: > > On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > > > I doubt that QEMU n900 boots in secure mode but instead shows > > > the SoC as general purpose SoC. If so, you'd have to patch

Re: n900 in next-20170901

* Joonsoo Kim [170913 00:54]: > On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > > I doubt that QEMU n900 boots in secure mode but instead shows > > the SoC as general purpose SoC. If so, you'd have to patch the > > omap3_save_secure_ram_context() to

Re: n900 in next-20170901

* Joonsoo Kim [170913 00:54]: > On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > > I doubt that QEMU n900 boots in secure mode but instead shows > > the SoC as general purpose SoC. If so, you'd have to patch the > > omap3_save_secure_ram_context() to attempt to save secure RAM > >

Re: n900 in next-20170901

On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170907 00:30]: > > On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > > > Hi, > > > > > > * Joonsoo Kim [170905 16:32]: > > > > I think that I made a

Re: n900 in next-20170901

On Thu, Sep 07, 2017 at 09:16:51AM -0700, Tony Lindgren wrote: > * Joonsoo Kim [170907 00:30]: > > On Wed, Sep 06, 2017 at 06:30:57AM -0700, Tony Lindgren wrote: > > > Hi, > > > > > > * Joonsoo Kim [170905 16:32]: > > > > I think that I made a mistake for configuration CONFIG_HIGHMEM=y and > >

  1   2   >