[Linux-Xtensa] [PATCH v3] xtensa: remap io area defined in device tree

Max Filippov jcmvbkbc at gmail.com
Mon Dec 30 07:31:24 UTC 2013


On Mon, Dec 30, 2013 at 10:32 AM, Baruch Siach <baruch at tkos.co.il> wrote:
> Hi Max,
>
> On Mon, Dec 30, 2013 at 10:13:34AM +0400, Max Filippov wrote:
>> On Sun, Dec 29, 2013 at 1:03 PM, Baruch Siach <baruch at tkos.co.il> wrote:
>> > Use the simple-bus node to discover the io area, and remap the cached and
>> > bypass io ranges. The parent-bus-address value of the first triplet in the
>> > "ranges" property is used. This value is rounded down to the nearest 256MB
>> > boundary. The length of the io area is fixed at 256MB; the "ranges" property
>> > length value is ignored.
>> >
>> > Other limitations: (1) only the first simple-bus node is considered, and (2)
>> > only the first triplet of the "ranges" property is considered.
>> >
>> > See ePAPR 1.1 §6.5 for the simple-bus node description, and §2.3.8 for the
>> > "ranges" property description.
>> >
>> > Signed-off-by: Baruch Siach <baruch at tkos.co.il>
>>
>> I've fixed up a couple of nits mentioned below and applied the whole series to
>> the xtensa-fixes-for-upstream branch of my tree. I've also tested that it builds
>> and boots in couple configurations, with and without xtensa_kio_paddr.
>>
>> Please let me know if it's ok, or you want to further change the series.
>
> Thanks. One comments below.
>
>> > @@ -234,6 +269,7 @@ void __init early_init_devtree(void *params)
>> >                 dt_memory_scan = true;
>> >
>> >         early_init_dt_scan(params);
>> > +       of_scan_flat_dt(xtensa_dt_io_area, NULL);
>>
>> This hunk didn't apply to v3.12, please check my resolution.
>
> I'm not sure the resolution of this conflict for Linus would be
> straightforward. Wouldn't it be easier to just rebase on top of v3.13-rc?

Ok, I'll rebase it once our for_next gets untangled.

-- 
Thanks.
-- Max


More information about the linux-xtensa mailing list