On Sun, 11 Mar 2018 23:04:02 -0500
Nick French wrote:
> On Sun, Mar 11, 2018 at 11:24:38PM +, Ian Armstrong wrote:
> > On Sat, 10 Mar 2018 16:57:41 +
> > "French, Nicholas A." wrote:
> >
> > > > > No what if the framebuffer driver is just requested as a
> > > > > secondary step after
On Sun, Mar 11, 2018 at 11:24:38PM +, Ian Armstrong wrote:
> On Sat, 10 Mar 2018 16:57:41 +
> "French, Nicholas A." wrote:
>
> > > > No what if the framebuffer driver is just requested as a
> > > > secondary step after firmware loading?
> > >
> > > Its a possibility. The decoder firmwar
On Sat, 10 Mar 2018 16:57:41 +
"French, Nicholas A." wrote:
> > > No what if the framebuffer driver is just requested as a
> > > secondary step after firmware loading?
> >
> > Its a possibility. The decoder firmware gets loaded at the
> > beginning of the decoder memory range and we know it
On Sun, Mar 11, 2018 at 01:19:03PM -0700, Andy Lutomirski wrote:
> From memory, I see two potentially reasonable real fixes. One is to find a
> way to punch a hole in an ioremap.
> So you’d find the framebuffer, remove it from theproblematic mapping, and
> then make a new mapping.
> The second i
> On Mar 11, 2018, at 12:51 PM, Nick French wrote:
>
> On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote:
Perhaps the easy answer is to change the fatal is-pat-enabled check to just
a warning like "you have PAT enabled, so wc is disabled for the
framebuffer.
On Sat, Mar 10, 2018 at 10:20:23AM -0800, Andy Lutomirski wrote:
>>> Perhaps the easy answer is to change the fatal is-pat-enabled check to just
>>> a warning like "you have PAT enabled, so wc is disabled for the framebuffer.
>>> if you want wc, use the nopat parameter"?
>>
>> I like this idea more
On Sat, Mar 10, 2018 at 11:03 AM, Luis R. Rodriguez wrote:
> On Sat, Mar 10, 2018 at 8:57 AM, French, Nicholas A. wrote:
>> On Wed, Mar 07, 2018 at 11:23:09PM -0600, French, Nicholas A. wrote:
>>> On Thu, Mar 08, 2018 at 04:14:11AM +, Luis R. Rodriguez wrote:
>>> > On Thu, Mar 08, 2018 at 04:
On Sat, Mar 10, 2018 at 8:57 AM, French, Nicholas A. wrote:
> On Wed, Mar 07, 2018 at 11:23:09PM -0600, French, Nicholas A. wrote:
>> On Thu, Mar 08, 2018 at 04:14:11AM +, Luis R. Rodriguez wrote:
>> > On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
>> > > On Thu, Mar 08, 20
> On Mar 10, 2018, at 8:57 AM, French, Nicholas A. wrote:
>
>> On Wed, Mar 07, 2018 at 11:23:09PM -0600, French, Nicholas A. wrote:
>>> On Thu, Mar 08, 2018 at 04:14:11AM +, Luis R. Rodriguez wrote:
On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
> On Thu, Mar 0
On Wed, Mar 07, 2018 at 11:23:09PM -0600, French, Nicholas A. wrote:
> On Thu, Mar 08, 2018 at 04:14:11AM +, Luis R. Rodriguez wrote:
> > On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
> > > On Thu, Mar 08, 2018 at 03:16:29AM +, French, Nicholas A. wrote:
> > > >
> > > >
On Thu, Mar 08, 2018 at 04:14:11AM +, Luis R. Rodriguez wrote:
> On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
> > On Thu, Mar 08, 2018 at 03:16:29AM +, French, Nicholas A. wrote:
> > >
> > > Ah, I see. So my proposed ioremap_wc call was only "working" by aliasing
>
On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
> On Thu, Mar 08, 2018 at 03:16:29AM +, French, Nicholas A. wrote:
> > On Wed, Mar 07, 2018 at 07:02:05PM +, Luis R. Rodriguez wrote:
> > > On Tue, Mar 06, 2018 at 09:01:10PM +, French, Nicholas A. wrote:
> > > > any rea
On Thu, Mar 08, 2018 at 03:16:29AM +, French, Nicholas A. wrote:
> On Wed, Mar 07, 2018 at 07:02:05PM +, Luis R. Rodriguez wrote:
> > On Tue, Mar 06, 2018 at 09:01:10PM +, French, Nicholas A. wrote:
> > > any reason why PAT can't be enabled for ivtvfb as simply as in the
> > > attached
On Wed, Mar 07, 2018 at 07:02:05PM +, Luis R. Rodriguez wrote:
> On Tue, Mar 06, 2018 at 09:01:10PM +, French, Nicholas A. wrote:
> > any reason why PAT can't be enabled for ivtvfb as simply as in the attached
> > patch?
>
> Prior to your change the OSD buffer was obtained using the itv->de
On Tue, Mar 06, 2018 at 09:01:10PM +, French, Nicholas A. wrote:
> any reason why PAT can't be enabled for ivtvfb as simply as in the attached
> patch?
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 621b2f613d81..69de110726e8 100644
--- a/drivers/media/pci
/media/ivtv: Use arch_phys_wc_add() and require PAT disabled
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future, we
also want to make the default behavior of ioremap_nocache()
to use strong UC, at which point the use of mtrr_add() on
those
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future, we
also want to make the default behavior of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
On 06/09/2015 02:56 AM, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Jun 2015 17:20:20 -0700
> "Luis R. Rodriguez" escreveu:
>
>> From: "Luis R. Rodriguez"
>>
>> We are burrying direct access to MTRR code support on
>> x86 in order to take advantage of PAT. In the future we
>> also want to make the
Em Mon, 08 Jun 2015 17:20:20 -0700
"Luis R. Rodriguez" escreveu:
> From: "Luis R. Rodriguez"
>
> We are burrying direct access to MTRR code support on
> x86 in order to take advantage of PAT. In the future we
> also want to make the default behaviour of ioremap_nocache()
> to use strong UC, use
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
On Mon, 2015-04-27 at 09:43 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> We are burrying direct access to MTRR code support on
> x86 in order to take advantage of PAT. In the future we
> also want to make the default behaviour of ioremap_nocache()
> to use strong UC, use of mtr
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
On Sat, Apr 25, 2015 at 07:12:05AM -0400, Andy Walls wrote:
> Hi Luis,
>
> Sorry for the late reply.
>
> Thank you for the patch! See my comments below:
>
> On Wed, 2015-04-22 at 12:33 -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez"
> >
> > We are burrying direct access to MTRR c
Hi Luis,
Sorry for the late reply.
Thank you for the patch! See my comments below:
On Wed, 2015-04-22 at 12:33 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> We are burrying direct access to MTRR code support on
> x86 in order to take advantage of PAT. In the future we
> also
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
29 matches
Mail list logo
