lkml.org 
[lkml]   [2016]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Issue with ioremap
On Fri, Apr 01, 2016 at 01:13:06AM +0530, punnaiah choudary kalluri wrote:
> Hi,
>
> We are using the pl353 smc controller for interfacing the nand in our zynq SOC.
> The driver for this controller is currently under mainline review.
> Recently we are moved to 4.4 kernel and observing issues with the driver.
> while debug, found that the issue is with the virtual address returned from
> the ioremap is not aligned to the physical address and causing nand
> access failures.
> the nand controller physical address starts at 0xE1000000 and the size is 16MB.
> the ioremap function in 4.3 kernel returns the virtual address that is
> aligned to the size
> but not the case in 4.4 kernel.

:(. I had actually ran into this, too, as I was evaluating the use of
the upstream-targetted pl353 stuff; sorry I didn't say anything.

> this controller uses the bits [31:24] as base address and use rest all
> bits for configuring adders cycles, chip select information. so it
> expects the virtual address also aligned to 0xFF000000 otherwise the
> nand commands issued will fail.

The driver _currently_ expects the virtual address to be 16M aligned,
but is that a hard requirement? It seems possible that the driver could
be written without this assumption, correct?

This would mean that the driver would need to maintain the cs/cycles
configuration state outside of the mapped virtual address, and then
calculate + add the calculated offset to the base. Would that work?
I had been meaning to give it a try, but haven't gotten around to it.

Josh

\
 
 \ /
  Last update: 2016-03-31 22:21    [W:0.059 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site