mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>,
	Rouven Czerwinski <r.czerwinski@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
Date: Tue, 10 Nov 2020 10:36:39 +0100	[thread overview]
Message-ID: <25af706b-3cb1-c7d0-579a-b900ef674692@pengutronix.de> (raw)
In-Reply-To: <20201110091543.GP29830@pengutronix.de>

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
  - MMU off => does normal request_iomem_region when MMU is off
  - MMU on  => remaps reg to virtual-reg and does request_iomem_region

Advantages:
  - No extra board code
  - Reusable for others as well
  - No device tree patching necessary

I am not familiar with the PowerPC support in barebox, but if we keep the MMU
on, then the use of virtual-reg is correct and if we turn it off, it doesn't
hurt to have it, so we should be within spec.

Let me know what you think.
Cheers,
Ahmad

> 
> Sascha
> 
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2020-11-10  9:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 1/8] ARM: MMU: add zero_page_{access,faulting} Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping Rouven Czerwinski
2020-11-09 13:52   ` Lucas Stach
2020-11-10  6:33     ` Rouven Czerwinski
2020-11-10  7:48       ` Sascha Hauer
2020-11-10  9:15         ` Sascha Hauer
2020-11-10  9:36           ` Ahmad Fatoum [this message]
2020-11-10  9:43             ` Ahmad Fatoum
2020-11-12 10:06               ` Sascha Hauer
2020-11-12 10:09                 ` Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 3/8] amba: add *_amba_driver helper macros Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 4/8] ARM: vexpress: remove unused KConfig file Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 5/8] ARM: vexpress: convert to board driver Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 6/8] ARM: vexpress: move Options to ARCH_VEXPRESS Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 7/8] ARM: qemu: add support for qemu virt platform Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 8/8] ARM: vexpress: enable VIRT board, MMU and cmds Rouven Czerwinski
2020-11-12 10:30 ` [PATCH 0/8] QEMU virt machine support via mach-vexpress Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25af706b-3cb1-c7d0-579a-b900ef674692@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=r.czerwinski@pengutronix.de \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox