Hi Yisheng,
On 4/11/2018 6:52 AM, Yisheng Xie wrote:
Hi Tomasz,
On 2018/4/10 21:14, Tomasz Figa wrote:
Hi Yisheng,
Sorry, I think we missed your question here.
On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote:
Hi Vivek,
On 2018/3/28 12:37, Vivek Gautam wrote:
Hi Yisheng
On 3/28/2018
Hi Tomasz,
On 2018/4/10 21:14, Tomasz Figa wrote:
> Hi Yisheng,
>
> Sorry, I think we missed your question here.
>
> On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote:
>
>> Hi Vivek,
>
>> On 2018/3/28 12:37, Vivek Gautam wrote:
>>> Hi Yisheng
>>>
>>>
>>> On 3/28/2018 6:54 AM, Yisheng Xie wrot
On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if
On Fri, Mar 30, 2018 at 01:24:44PM +0530, Nipun Gupta wrote:
> It is bus specific aspect to map a given device on the bus and
> relevant firmware description of its DMA configuration.
> So, this change introduces 'dma_configure' as bus callback
> giving flexibility to busses for implementing its ow
On 2/12/2018 1:33 PM, Jean-Philippe Brucker wrote:
> +static void io_mm_detach_all_locked(struct iommu_bond *bond)
> +{
> + while (!io_mm_detach_locked(bond));
> +}
> +
I don't remember if I mentioned this before or not but I think this loop
needs a little bit relaxation with yield and maybe a
On Tue, Apr 10, 2018 at 06:50:04PM +0100, Robin Murphy wrote:
> In the first one, the machine appears to have enough RAM that most of it is
> beyond the device's 36-bit DMA mask, thus it's fairly likely for the
> initial direct alloc to come back with something unsuitable.
But we should try a GF
On 10/04/18 18:07, Takashi Iwai wrote:
On Tue, 10 Apr 2018 19:06:15 +0200,
Christoph Hellwig wrote:
On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote:
The code refactoring by commit 0176adb00406 ("swiotlb: refactor
coherent buffer allocation") made swiotlb_alloc_buffer() almost alwa
On Tue, 10 Apr 2018 19:06:15 +0200,
Christoph Hellwig wrote:
>
> On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote:
> > The code refactoring by commit 0176adb00406 ("swiotlb: refactor
> > coherent buffer allocation") made swiotlb_alloc_buffer() almost always
> > failing due to a thinko:
The code refactoring by commit 0176adb00406 ("swiotlb: refactor
coherent buffer allocation") made swiotlb_alloc_buffer() almost always
failing due to a thinko: namely, the function evaluates the
dma_coherent_ok() call incorrectly and dealing as if it's invalid.
This ends up with weird errors like i
On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote:
> The code refactoring by commit 0176adb00406 ("swiotlb: refactor
> coherent buffer allocation") made swiotlb_alloc_buffer() almost always
> failing due to a thinko: namely, the function evaluates the
> dma_coherent_ok() call incorrectly
Hi Yisheng,
Sorry, I think we missed your question here.
On Wed, Mar 28, 2018 at 3:12 PM Yisheng Xie wrote:
> Hi Vivek,
> On 2018/3/28 12:37, Vivek Gautam wrote:
> > Hi Yisheng
> >
> >
> > On 3/28/2018 6:54 AM, Yisheng Xie wrote:
> >> Hi Vivek,
> >>
> >> On 2018/3/13 16:55, Vivek Gautam wrote:
Hi Robin,
Am Dienstag, 10. April 2018, 13:18:48 CEST schrieb Robin Murphy:
> On 10/04/18 10:26, Heiko Stuebner wrote:
> > Rockchip IOMMUs are used without explicit clock handling for 4 years
> > now, so we should keep compatibility with old devicetrees if possible.
> > Therefore make iommu clocks
On 10/04/18 10:26, Heiko Stuebner wrote:
iommu clocks are optional, so the driver should not fail if they are not
present. Instead just set the number of clocks to 0, which the clk-blk APIs
can handle just fine.
Fixes: f2e3a5f557ad ("iommu/rockchip: Control clocks needed to access the
IOMMU")
S
On 10/04/18 10:26, Heiko Stuebner wrote:
Rockchip IOMMUs are used without explicit clock handling for 4 years
now, so we should keep compatibility with old devicetrees if possible.
Therefore make iommu clocks optional.
Do we need to touch the binding itself? Obviously the driver has to
treat c
iommu clocks are optional, so the driver should not fail if they are not
present. Instead just set the number of clocks to 0, which the clk-blk APIs
can handle just fine.
Fixes: f2e3a5f557ad ("iommu/rockchip: Control clocks needed to access the
IOMMU")
Signed-off-by: Heiko Stuebner
---
drivers/
Rockchip IOMMUs are used without explicit clock handling for 4 years
now, so we should keep compatibility with old devicetrees if possible.
Therefore make iommu clocks optional.
Fixes: 8fa9eb39c614 ("dt-bindings: iommu/rockchip: Add clock property")
Signed-off-by: Heiko Stuebner
---
Documentatio
The newly added clock handling makes iommu clocks required, thus breaking
devicetrees from the last 4 years.
This series fixes the binding and driver to work without clocks being
present, like it did before and should therefore probably go in as fix
on top of the clock-handling patch.
Heiko Stue
Hi Christoph,
On Mon, Apr 09, 2018 at 10:52:51AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 09, 2018 at 06:59:08PM +0200, Jacopo Mondi wrote:
> > I'm still a bit puzzled on what happens if dma_mmap_from_dev_coherent()
> > fails.
> > Does a dma_mmap_from_dev_coherent() failure guarantee anyhow
18 matches
Mail list logo
