On 2019-01-24 12:45 p.m., Ard Biesheuvel wrote:
> On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> wrote:
>> Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
>>> On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
>>> wrote:
Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> [SNIP]
> This is *e
On Thu, Jan 24, 2019 at 8:57 AM Ard Biesheuvel
wrote:
>
> On Thu, 24 Jan 2019 at 14:54, Alex Deucher wrote:
> >
> > On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel
> > wrote:
> > >
> > > On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> > > wrote:
> > > >
> > > > Am 24.01.19 um 12:26 schrieb Ard
On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> > [SNIP]
> > This is *exactly* my point the whole time.
> >
> > The current code has
> >
> > static inline bool drm_arch_can_wc_memory(void)
> > {
> > #if defined(CONFIG_PPC) && !defined(CONFI
On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
wrote:
>
> Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > wrote:
> >> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> >>> [SNIP]
> >>> This is *exactly* my point the whole time.
> >>>
> >>> The cu
On Thu, 24 Jan 2019 at 10:31, Michel Dänzer wrote:
>
> On 2019-01-23 5:52 p.m., Ard Biesheuvel wrote:
> > On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
> >>
> >> I think we just want a driver-local check for those combinations
> >> where we know this hack actually works, which really jus
On Thu, 24 Jan 2019 at 14:54, Alex Deucher wrote:
>
> On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel
> wrote:
> >
> > On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> > wrote:
> > >
> > > Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > > > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > >
On Thu, 24 Jan 2019 at 10:45, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:28 schrieb Ard Biesheuvel:
> > On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
> > wrote:
> >> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> >>> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
>
On Thu, Jan 24, 2019 at 6:45 AM Ard Biesheuvel
wrote:
>
> On Thu, 24 Jan 2019 at 12:37, Koenig, Christian
> wrote:
> >
> > Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> > > On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> > > wrote:
> > >> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> > >>> [
On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
wrote:
>
> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> > On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
> >> But my concern is that it seems likely that non-cache coherent
> >> implementations are relying on this hack as well.
On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
> But my concern is that it seems likely that non-cache coherent
> implementations are relying on this hack as well. There must be a
> reason that this hack is only disabled for PowerPC platforms if they
> are cache coherent, for insta
Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
>>> [SNIP]
>>> This is *exactly* my point the whole time.
>>>
>>> The current code has
>>>
>>> static inline bool drm_arch_can_wc_memory(void)
>>>
Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> [SNIP]
> This is *exactly* my point the whole time.
>
> The current code has
>
> static inline bool drm_arch_can_wc_memory(void)
> {
> #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
> return false;
>
> which means the optimization i
Am 24.01.19 um 10:28 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
>>> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
But my concern is that it seems likely that non-cache coherent
im
On 2019-01-23 5:52 p.m., Ard Biesheuvel wrote:
> On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
>>
>> I think we just want a driver-local check for those combinations
>> where we know this hack actually works, which really just seems
>> to be x86-64 with PAT. Something like the patch below
Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
>> But my concern is that it seems likely that non-cache coherent
>> implementations are relying on this hack as well. There must be a
>> reason that this hack is only disabled for Powe
I think we just want a driver-local check for those combinations
where we know this hack actually works, which really just seems
to be x86-64 with PAT. Something like the patch below, but maybe with
even more strong warnings to not do something like this elsewhere:
diff --git a/drivers/gpu/drm/amd
On Wed, 23 Jan 2019 at 17:44, Christoph Hellwig wrote:
>
> I think we just want a driver-local check for those combinations
> where we know this hack actually works, which really just seems
> to be x86-64 with PAT. Something like the patch below, but maybe with
> even more strong warnings to not d
On Wed, 23 Jan 2019 at 08:15, Christoph Hellwig wrote:
>
> On Tue, Jan 22, 2019 at 10:07:07PM +0100, Ard Biesheuvel wrote:
> > Yes, so much was clear. And the reason this breaks on some arm64
> > systems is because
> > a) non-snooped PCIe TLP attributes may be ignored, and
> > b) non-x86 CPUs do n
On Tue, Jan 22, 2019 at 10:07:07PM +0100, Ard Biesheuvel wrote:
> Yes, so much was clear. And the reason this breaks on some arm64
> systems is because
> a) non-snooped PCIe TLP attributes may be ignored, and
> b) non-x86 CPUs do not snoop the caches when accessing uncached mappings.
>
> I don't t
On Tue, 22 Jan 2019 at 21:56, Alex Deucher wrote:
>
> On Tue, Jan 22, 2019 at 4:19 AM Ard Biesheuvel
> wrote:
> >
> > On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
> > >
> > > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > > > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
> > > >>
On Tue, Jan 22, 2019 at 4:19 AM Ard Biesheuvel
wrote:
>
> On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
> >
> > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
> > >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> > >>> On Mon, 21 Ja
On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
>
> On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
> >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
> On 2019-01-21 6:59 p.m.
On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
>
> On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
> >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
> On 2019-01-21 6:59 p.m.
On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
>> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 18:55, Mich
On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
>
> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
> >>
> >> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>
> On 2019-01-
On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
>
> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
> >>
> >> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig
> >>> wrote:
> >>>
> U
On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
>>
>> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 17:
On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>>
>> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
>>> On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
>>>
Until that happens we should just change the driver ifdefs to default
t
On Mon, 21 Jan 2019 at 17:35, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 05:30:00PM +0100, Ard Biesheuvel wrote:
> > > Until that happens we should just change the driver ifdefs to default
> > > the hacks to off and only enable them on setups where we 100%
> > > positively know that they
On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>
> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
> >
> >> Until that happens we should just change the driver ifdefs to default
> >> the hacks to off and only enable them on setups wher
On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
>
>> Until that happens we should just change the driver ifdefs to default
>> the hacks to off and only enable them on setups where we 100%
>> positively know that they actually work. And docu
On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 05:14:37PM +0100, Ard Biesheuvel wrote:
> > > I'll add big fat comments. But the fact that nothing is exported
> > > there should be a fairly big hint.
> > >
> >
> > I don't follow. How do other header files 'expor
On Mon, 21 Jan 2019 at 16:59, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote:
> > >
> > > > +#include
> > >
> > > This header is not for usage in device drivers, but purely for
> > > dma-mappi
On Mon, Jan 21, 2019 at 05:30:00PM +0100, Ard Biesheuvel wrote:
> > Until that happens we should just change the driver ifdefs to default
> > the hacks to off and only enable them on setups where we 100%
> > positively know that they actually work. And document that fact
> > in big fat comments.
>
On Mon, Jan 21, 2019 at 05:14:37PM +0100, Ard Biesheuvel wrote:
> > I'll add big fat comments. But the fact that nothing is exported
> > there should be a fairly big hint.
> >
>
> I don't follow. How do other header files 'export' things in a way
> that this header doesn't?
Well, I'll add commen
On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote:
> On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote:
> >
> > > +#include
> >
> > This header is not for usage in device drivers, but purely for
> > dma-mapping implementations!
> >
>
> Is that documented anywhere?
I'll add big
On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote:
>
> > +#include
>
> This header is not for usage in device drivers, but purely for
> dma-mapping implementations!
>
Is that documented anywhere?
> > +static inline bool drm_device_can_wc_memory(struct drm_device *ddev)
> > {
> > + if (
> +#include
This header is not for usage in device drivers, but purely for
dma-mapping implementations!
> +static inline bool drm_device_can_wc_memory(struct drm_device *ddev)
> {
> + if (IS_ENABLED(CONFIG_PPC))
> + return IS_ENABLED(CONFIG_NOT_COHERENT_CACHE);
> + else if (
Currently, the DRM code assumes that PCI devices are always cache
coherent for DMA, and that this can be selectively overridden for
some buffers using non-cached mappings on the CPU side and PCIe
NoSnoop transactions on the bus side.
Whether the NoSnoop part is implemented correctly is highly plat
Am 21.01.19 um 11:06 schrieb Ard Biesheuvel:
> Currently, the DRM code assumes that PCI devices are always cache
> coherent for DMA, and that this can be selectively overridden for
> some buffers using non-cached mappings on the CPU side and PCIe
> NoSnoop transactions on the bus side.
>
> Whether
40 matches
Mail list logo
