linux-kernel - Re: [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2C85F818-5612-4A53-A558-B633315B8D37@aosc.io>
Date:   Fri, 21 Apr 2017 16:18:57 +0800
From:   icenowy@...c.io
To:     linux-arm-kernel@...ts.infradead.org,
        Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc:     devicetree@...r.kernel.org,
        Jernej Skrabec <jernej.skrabec@...l.net>,
        David Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org, linux-sunxi@...glegroups.com,
        Rob Herring <robh+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>,
        linux-clk@...r.kernel.org
Subject: Re: [PATCH v4 06/11] drm/sun4i: add support for Allwinner DE2 mixers


于 2017年4月20日 GMT+08:00 下午4:37:07, Maxime Ripard 
<maxime.ripard@...e-electrons.com> 写到:
> On Tue, Apr 18, 2017 at 06:47:56PM +0800, Icenowy Zheng wrote:
>> >> +	/* Get the physical address of the buffer in memory */
>> >> +	gem = drm_fb_cma_get_gem_obj(fb, 0);
>> >> +
>> >> +	DRM_DEBUG_DRIVER("Using GEM @ %pad\n", &gem->paddr);
>> >> +
>> >> +	/* Compute the start of the displayed memory */
>> >> +	bpp = fb->format->cpp[0];
>> >> +	paddr = gem->paddr + fb->offsets[0];
>> >> +	paddr += (state->src_x >> 16) * bpp;
>> >> +	paddr += (state->src_y >> 16) * fb->pitches[0];
>> >> +
>> >> +	DRM_DEBUG_DRIVER("Setting buffer address to %pad\n", &paddr);
>> >> +
>> >> +	paddr_u32 = (uint32_t) paddr;
>> >
>> >How does that work on 64-bits systems ?
>> 
>> The hardware is not designed to work on 64-bit systems.
>> 
>> Even 64-bit A64/H5 has also 3GiB memory limit.
> 
> That's a fragile assumption.

Yes, it's only the basical reason.

> 
>> The address cell in mixer hardware is also only 32-bit.
>> 
>> So we should just keep the force conversion here. If we then really
>> met 4GiB-capable AW SoC without changing DE2, I think we should have
>> other way to limit CMA pool inside 4GiB.
> 
> The register name looks like this is only the lower 32 bits that you
> can set here, and that there is another register for the upper 32 bits
> of that address somewhere.

Maybe... but no one can verify this as their's no currently any user
which has 4GiB+ DRAM.

I think we should keep this until Allwinner really made a 4GiB-capable
hardware.

> 
> In that case, please use the lower_32_bits and upper_32_bits helper,
> and don't cast it that way.
> 
> If it isn't the case, you should set the DMA mask (through
> dma_set_mask) so that we only allocate memory that can be accessed by
> this device.

How to do it?

> 
> Maxime