On 15/05/2017 15:54, Stefan Wahren wrote:
> Am 15.05.2017 um 16:29 schrieb Phil Elwell:
>> On 13/05/2017 10:30, Russell King - ARM Linux wrote:
>>> On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
In the meantime this issue has been fixed by Phil [1].
>>> Right - definitely a dri
Am 15.05.2017 um 16:29 schrieb Phil Elwell:
> On 13/05/2017 10:30, Russell King - ARM Linux wrote:
>> On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
>>> In the meantime this issue has been fixed by Phil [1].
>> Right - definitely a driver bug. Mapping more memory for DMA than is
>>
On 13/05/2017 10:30, Russell King - ARM Linux wrote:
> On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
>> In the meantime this issue has been fixed by Phil [1].
>
> Right - definitely a driver bug. Mapping more memory for DMA than is
> actually going to be DMA'd to and expecting da
On Sat, May 13, 2017 at 11:07:28AM +0200, Stefan Wahren wrote:
> In the meantime this issue has been fixed by Phil [1].
Right - definitely a driver bug. Mapping more memory for DMA than is
actually going to be DMA'd to and expecting data to be preserved is
really horrid.
> Unfortunately i found
> Stefan Wahren hat am 24. April 2017 um 21:35
> geschrieben:
>
>
>
> > Russell King - ARM Linux hat am 24. April 2017 um
> > 20:59 geschrieben:
> >
> >
> > On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote:
> > > > What I can't see is how changing flush_dcache_page() has poss
> Russell King - ARM Linux hat am 24. April 2017 um
> 20:59 geschrieben:
>
>
> On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote:
> > > What I can't see is how changing flush_dcache_page() has possibly broken
> > > this: it seems to imply that you're getting flush_dcache_page() som
On Mon, Apr 24, 2017 at 07:42:27PM +0200, Stefan Wahren wrote:
> > What I can't see is how changing flush_dcache_page() has possibly broken
> > this: it seems to imply that you're getting flush_dcache_page() somehow
> > called inbetween mapping it for DMA, using it for DMA and CPU accesses
> > occu
> Russell King - ARM Linux hat am 24. April 2017 um
> 18:40 geschrieben:
>
>
> On Mon, Apr 24, 2017 at 06:12:09PM +0200, Stefan Wahren wrote:
> > Am 20.04.2017 um 21:58 schrieb Rabin Vincent:
> > > On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
> > >> I'm confused by what you're
On Mon, Apr 24, 2017 at 06:12:09PM +0200, Stefan Wahren wrote:
> Am 20.04.2017 um 21:58 schrieb Rabin Vincent:
> > On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
> >> I'm confused by what you're saying here. The driver has already been
> >> converted to not use dmac_map_area (commit
Am 20.04.2017 um 21:58 schrieb Rabin Vincent:
> On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
>> I'm confused by what you're saying here. The driver has already been
>> converted to not use dmac_map_area (commit
>> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg inste
Rabin Vincent writes:
> On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
>> I'm confused by what you're saying here. The driver has already been
>> converted to not use dmac_map_area (commit
>> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
>> matching the ra
On Thu, Apr 20, 2017 at 11:27:38AM -0700, Eric Anholt wrote:
> I'm confused by what you're saying here. The driver has already been
> converted to not use dmac_map_area (commit
> cf9caf1929882b66922aee698e99e6c8f357bee5), and uses dma_map_sg instead,
> matching the radeon driver you give as a mode
Rabin Vincent writes:
> On Thu, Apr 13, 2017 at 11:29:15PM +0100, Russell King - ARM Linux wrote:
>> > 00a19f3e25c0c40e0ec77f52d4841d23ad269169 is the first bad commit
>> > commit 00a19f3e25c0c40e0ec77f52d4841d23ad269169
>> > Author: Rabin Vincent
>> > Date: Tue Nov 8 09:21:19 2016 +0100
>> >
Hi Rabin,
> Rabin Vincent hat am 14. April 2017 um 09:41 geschrieben:
>
>
> On Thu, Apr 13, 2017 at 11:29:15PM +0100, Russell King - ARM Linux wrote:
> > > 00a19f3e25c0c40e0ec77f52d4841d23ad269169 is the first bad commit
> > > commit 00a19f3e25c0c40e0ec77f52d4841d23ad269169
> > > Author: Rabin
On Thu, Apr 13, 2017 at 11:29:15PM +0100, Russell King - ARM Linux wrote:
> > 00a19f3e25c0c40e0ec77f52d4841d23ad269169 is the first bad commit
> > commit 00a19f3e25c0c40e0ec77f52d4841d23ad269169
> > Author: Rabin Vincent
> > Date: Tue Nov 8 09:21:19 2016 +0100
> >
> > ARM: 8627/1: avoid cac
On Thu, Apr 13, 2017 at 07:41:48PM +0200, Stefan Wahren wrote:
> > Stefan Wahren hat am 11. April 2017 um 20:10
> > geschrieben:
> >
> >
> > Hi,
> >
> > recently i found that vchiq_test -f doesn't work anymore with current
> > mainline (4.11-rc6) and linux-next (20170404) on my Raspberry Pi Z
> Stefan Wahren hat am 11. April 2017 um 20:10
> geschrieben:
>
>
> Hi,
>
> recently i found that vchiq_test -f doesn't work anymore with current
> mainline (4.11-rc6) and linux-next (20170404) on my Raspberry Pi Zero. The
> issue is always reproducible, but the error behavior isn't determin
Hi,
recently i found that vchiq_test -f doesn't work anymore with current mainline
(4.11-rc6) and linux-next (20170404) on my Raspberry Pi Zero. The issue is
always reproducible, but the error behavior isn't deterministic. Sometimes
vchiq_test hangs and sometimes i get an error message from vch
18 matches
Mail list logo
