On Thu, 2020-11-12 at 11:06 +0100, Sascha Hauer wrote:
> On Tue, Nov 10, 2020 at 10:43:30AM +0100, Ahmad Fatoum wrote:
> > On 11/10/20 10:36 AM, Ahmad Fatoum wrote:
> > > Hi,
> > >
> > > On 11/10/20 10:15 AM, Sascha Hauer wrote:
> > > > On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
> > > > > On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski
> > > > > wrote:
> > > > > > On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> > > > > > > Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven
> > > > > > > Czerwinski:
> > > > > > > > Annotate the different read and write functions with
> > > > > > > > zero_page_{access/faulting}. This allows the cfi_flash
> > > > > > > > driver to be used
> > > > > > > > on the QEMU virt machine with an enabled MMU.
> > > > > > >
> > > > > > > I don't like this zero-page access allow in a driver at
> > > > > > > all. If you
> > > > > > > have some free address space somewhere, you could also
> > > > > > > solve this issue
> > > > > > > by remapping the IO resource to somewhere else in the
> > > > > > > address space,
> > > > > > > deviating from the 1:1 mapping. The Tegra PCIe host
> > > > > > > driver does this,
> > > > > > > if you need some inspiration.
> > > > > >
> > > > > > I totally agree, remapping the IO region sounds like a much
> > > > > > better
> > > > > > choice.
> > > > >
> > > > > But where should it be mapped to? Just 4k upwards and hope
> > > > > that the area
> > > > > just above the cfi flash isn't occupied by something else?
> > > >
> > > > Ok, here's the plan:
> > > >
> > > > In a board specific initcall map the memory to wherever it's
> > > > convenient,
> > > > modify the address of the CFI flash in the device node and add
> > > > a big
> > > > comment that there's nothing to see here.
> > >
> > > The device tree specification defines a "virtual-reg property
> > > [that] specifies
> > > an effective address that maps to the first physical address
> > > specified in
> > > the reg property of the device node. This property enables boot
> > > programs to
> > > provide client programs with virtual-to-physical mappings that
> > > have been set up".
> > >
> > > So, how about a tad more generic approach:
> > >
> > > - barebox device tree extends cfi-flash node with virtual-reg of
> > > appropriate
> > > location
> > > - Define a of_iomap() function that
> >
> > Or rather a more generic name, like dev_ioremap?.(In that case
> > !CONFIG_OF is the same as MMU off).
>
> I wouldn't use ioremap as name when the function has a different
> semantics, but other than that: Sounds good. Make it so!
This only works if you have available IOMEM big enough somewhere, which
is not the case on the qemu ARM virt platform. While I agree that
having MMU enabled is great for testing, maybe we can just add !MMU as
a dependency for the virt board.
Regards,
Rouven
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
