2018-02-03 0:29 GMT+01:00 Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>: > On Tue 30 Jan 05:25 PST 2018, Arnd Bergmann wrote: > >> On Tue, Jan 30, 2018 at 11:11 AM, Benjamin GAIGNARD >> <benjamin.gaignard@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
