Messages in this thread |  | | From | Benjamin Gaignard <> | Date | Sun, 4 Feb 2018 11:01:34 +0100 | Subject | Re: Compilation error report for: drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of ?dma_alloc_coherent? from incompatible pointer type |
| |
2018-02-03 0:29 GMT+01:00 Bjorn Andersson <bjorn.andersson@linaro.org>: > On Tue 30 Jan 05:25 PST 2018, Arnd Bergmann wrote: > >> On Tue, Jan 30, 2018 at 11:11 AM, Benjamin GAIGNARD >> <benjamin.gaignard@st.com> wrote: >> > >> > On 01/12/2018 05:11 PM, Arnaud Pouliquen wrote: >> >> Hello Andy,David, >> > + Arnd >> > >> > I have the same issue on drm-misc-next. >> > Does Arnaud's fix make sense or should we update/change the way of how >> > we compile the kernel ? >> >> We've hit a couple of bugs with qcom drivers confusing physical addresses >> and DMA addresses in the past, usually the drivers were buggy in >> some form, and tried to use dma_alloc_coherent() to get a buffer >> that gets passed into a firmware interface taking a physical address, >> which is of course completely wrong. >> > > Thanks Arnd, for once again using the words "bug" and "completely wrong" > when referring to something that obviously works just fine... >
I can't judge if using dma_alloc_coherent is correct or not here but, obviously, the type of the third parameter doesn't match dma_alloc_coherent prototype. May you consider to fix that ?
> > The solution you introduced for venus and adreno relies on static > reservations of system ram, which isn't pretty, but more importantly > isn't viable for the qcom_scm driver. > > > So, how do I dynamically allocate a chunk of coherent memory? > > Preferably with the possibility of unmapping it temporarily from Linux > while passing the buffer into the trusted environment (as any accesses > during the operation might cause access violations). > > Regards, > Bjorn
|  |