On Mon, May 14, 2018 at 07:35:03AM -0300, Mauro Carvalho Chehab wrote:
> Hi Fabien,
>
> Em Mon, 14 May 2018 08:00:37 +
> Fabien DESSENNE escreveu:
>
> > On 07/05/18 17:19, Mauro Carvalho Chehab wrote:
> > > Em Mon, 07 May 2018 16:26:08 +0300
> > > Laurent Pinchart escreveu:
> > >
> > >> H
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
On Thu, Mar 08, 2018 at 03:16:29AM +, French, Nicholas A. wrote:
> On Wed, Mar 07, 2018 at 07:02:05PM +0000, 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 ivt
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 +0000, Luis R. Rodriguez wrote:
> > > On Tue, Mar 06, 2018 at 09:01:10PM +, French, Nicholas A.
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 +0000, Luis R. Rodriguez wrote:
>> > On Thu, Mar 08, 2018 at 04:06:01AM +, Luis R. Rodriguez wrote:
>
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 Tue, Oct 03, 2017 at 03:09:53PM -0600, Shuah Khan wrote:
> On Tue, Oct 3, 2017 at 3:00 PM, Jiri Kosina wrote:
> > On Tue, 3 Oct 2017, Pavel Machek wrote:
> >
> >> > Again, I agree that the (rare) kthreads that are actually "creating" new
> >> > I/O have to be somehow frozen and require special
On Tue, Jun 23, 2015 at 12:39 AM, Ingo Molnar wrote:
> Same observation as for the other patch: please only warn if the hardware is
> present and the driver tries to activate. No need to annoy others.
Will fix, and respin.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-
From: "Luis R. Rodriguez"
The 0-day robot found that the notpat requirement warning was
being triggered on the ivtv driver on the module init path,
that will always trigger on built-in devices. We want that warning
to trigger only if real hardware is found so this moves the ivtv
w
From: "Luis R. Rodriguez"
WARN() may confuse users, fix that. ipath_init_one() is part the
device's probe so this would only be triggered if a corresponding
device was found.
Signed-off-by: Luis R. Rodriguez
---
drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
1
From: "Luis R. Rodriguez"
On built-in kernels this warning will always splat as this is part
of the module init. Fix that by shifting the PAT requirement check
out under the code that does the "quasi-probe" for the device. This
device driver relies on an existing driver to
On Thu, Jun 25, 2015 at 08:49:22AM +0200, Ingo Molnar wrote:
>
> * Luis R. Rodriguez wrote:
>
> > From: "Luis R. Rodriguez"
> >
> > WARN() may confuse users, fix that. ipath_init_one() is part the
> > device's probe so this would only be t
On Thu, Jun 25, 2015 at 08:51:47AM +0200, Ingo Molnar wrote:
>
> * Luis R. Rodriguez wrote:
>
> > From: "Luis R. Rodriguez"
> >
> > On built-in kernels this warning will always splat as this is part
> > of the module init. Fix that by shifting the P
On Mon, Jun 29, 2015 at 05:52:18AM -0400, Andy Walls wrote:
> On June 29, 2015 2:55:05 AM EDT, Ingo Molnar wrote:
> >
> >* Andy Walls wrote:
> >
> >> On Fri, 2015-06-26 at 10:45 +0200, Ingo Molnar wrote:
> >> > * Luis R. Rodriguez wrote:
> >> &
On Mon, Jul 6, 2015 at 5:44 PM, Luis R. Rodriguez wrote:
> If we really wanted to we could consider arch_phys_wc_add()
I mean adding a __arch_phys_wc_add() which does not check for pat_enabled().
> and
> deal with that this will not check for pat_enabled() and forces MTRR...
> I thi
From: "Luis R. Rodriguez"
On built-in kernels this warning will always splat as this is part
of the module init. Fix that by shifting the PAT requirement check
out under the code that does the "quasi-probe" for the device. This
device driver relies on an existing driver to
From: "Luis R. Rodriguez"
WARN() may confuse users, fix that. ipath_init_one() is part the
device's probe so this would only be triggered if a corresponding
device was found.
Signed-off-by: Luis R. Rodriguez
---
drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
1
From: "Luis R. Rodriguez"
Ingo,
Boris is on vacation so sending this through you. This is just a resend of
the v2 series. The issue here was the WARN() splat on built-in kernels due
to ivtv's funky probe which will trigger even if you don't have any ivtv
hardware. I&#
On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote:
> On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
>> >>> On 12.06.15 at 01:23, wrote:
>> > There are two usages on MTRRs:
>> > 1) MTRR entries set by firmware
>> > 2) MTRR entries set by OS drivers
>> >
>> > We can obsolete 2), but we hav
On Thu, Aug 6, 2015 at 12:53 PM, Luis R. Rodriguez
wrote:
> For those type of OSes...
> could it be possible to negotiate or hint to the platform through an
> attribute somehow that the OS has such capability to not use MTRR?
And if that's not possible how about a new platform sett
On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote:
> On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote:
>> On Fri, Jun 12, 2015 at 9:58 AM, Toshi Kani wrote:
>> > On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
>> > > > > > On 12.06.15 a
On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote:
> On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote:
>> On Thu, Aug 6, 2015 at 3:58 PM, Toshi Kani wrote:
>> > On Thu, 2015-08-06 at 12:53 -0700, Luis R. Rodriguez wrote:
>> > > On Fri, Jun 12, 2015
On Fri, Aug 7, 2015 at 4:08 PM, Toshi Kani wrote:
> On Fri, 2015-08-07 at 15:23 -0700, Luis R. Rodriguez wrote:
>> On Fri, Aug 7, 2015 at 2:56 PM, Toshi Kani wrote:
>> > On Fri, 2015-08-07 at 13:25 -0700, Luis R. Rodriguez wrote:
>> > > On Thu, Aug 6, 2015
From: "Luis R. Rodriguez"
The crusade to replace mtrr_add() with architecture agnostic
arch_phys_wc_add() is complete, this will ensure write-combining
implementations (PAT on x86) is taken advantage instead of using
MTRR. With the crusade done now, hide direct MTRR access for
driver
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"
> >
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.
I
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.
I
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.
I
From: "Luis R. Rodriguez"
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?
Boris,
provided the outcome of the above maintainer's preference for
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.
I
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: D
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.
I
On Mon, Jun 08, 2015 at 09:57:12PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Jun 2015 17:20:19 -0700
> "Luis R. Rodriguez" escreveu:
>
> > From: "Luis R. Rodriguez"
> >
> > Mauro,
> >
> > since the ivtv patch is already acke
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.
I
From: "Luis R. Rodriguez"
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?
Boris,
provided the outcome of the above maintainer's preference for
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.
I
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: D
On Thu, Jun 11, 2015 at 10:49:59AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Mauro,
>
> since the ivtv patch is already acked by the driver maintainer
> and depends on an x86 symbol that went through Boris' tree are you
> OK in it going
From: "Luis R. Rodriguez"
Boris,
the following patches make use of the newly exported pat_enabled()
which went in through your tree. All driver and respective subsystem
maintainers have Acked these patches and are OK for them to go in through
your tree. Please let me know if there any
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.
I
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: D
The series to bury direct MTRR use is almost all in and on its way to
v4.2. As the pending series continue slowly to be merged I wanted to
take the time to reiterate the justification for these changes in
hopes it may help those still reviewing some of these patches which
are pending and to help do
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.
I
On Thu, Jun 11, 2015 at 05:23:16PM -0600, Toshi Kani wrote:
> On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
> :
> > Pending RIP MTRR patches
> >
> >
> > There are a few pending series so I wanted to provide a status update
>
b/scm/linux/kernel/git/next/linux-next.git master
> >
> > commit 1bf1735b478008c30acaff18ec6f4a3ff211c28a
> > Author: Luis R. Rodriguez
> > AuthorDate: Mon Jun 15 10:28:16 2015 +0200
> > Commit: Ingo Molnar
> > CommitDate: Thu Jun 18 11:23:41 2015 +0200
&g
On Sun, Jun 21, 2015 at 10:41:20PM +0200, Borislav Petkov wrote:
> On Sun, Jun 21, 2015 at 10:23:48PM +0200, Luis R. Rodriguez wrote:
> > Nope, well the driver requires huge amounts of work to work with PAT,
> > that work will likely never be done, so hence the warning. Its our
&g
On Mon, Jun 22, 2015 at 09:06:41AM +0200, Borislav Petkov wrote:
> On Mon, Jun 22, 2015 at 03:01:38AM +0200, Luis R. Rodriguez wrote:
> > We can certainly replace the WARN() with pr_warn(), I don't see
> > how its confusing though as its a run time real issue. Either
> >
From: "Luis R. Rodriguez"
Mauro, Doug,
The 0-day robot found using WARN() on built-in kernels confusing. Upon
further thought pr_warn() is better and will likely also not confuse
humans too.
Boris, provided maintainers Ack, please consider these patches.
These depend on pat_enabled(
From: "Luis R. Rodriguez"
On built-in kernels this will always splat. Fix that.
Reported-by: Fengguang Wu [0-day test robot]
Signed-off-by: Luis R. Rodriguez
---
drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: "Luis R. Rodriguez"
On built-in kernels this will always splat. Fix that.
Reported-by: Fengguang Wu [0-day test robot]
Signed-off-by: Luis R. Rodriguez
---
drivers/media/pci/ivtv/ivtvfb.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/medi
From: "Luis R. Rodriguez"
spinlock_t should always be used.
CHECK drivers/watchdog/ie6xx_wdt.c
CC [M] drivers/watchdog/ie6xx_wdt.o
Building modules, stage 2.
MODPOST 43 modules
LD [M] drivers/watchdog/ie6xx_wdt.ko
Cc: Alexander Stein
Reported-by: Hauke Mehrtens
Sig
From: "Luis R. Rodriguez"
spinlock_t should always be used.
LD drivers/net/wireless/brcm80211/built-in.o
CHECK drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c
CC [M] drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.o
CHECK drivers/net/wireless/brcm8021
From: "Luis R. Rodriguez"
spinlock_t should always be used.
LD drivers/gpu/drm/i915/built-in.o
CHECK drivers/gpu/drm/i915/i915_drv.c
CC [M] drivers/gpu/drm/i915/i915_drv.o
CHECK drivers/gpu/drm/i915/i915_dma.c
CC [M] drivers/gpu/drm/i915/i915_dma.o
CHECK drive
From: "Luis R. Rodriguez"
spinlock_t should always be used.
Could not get this to build with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
M=drivers/media/platform/s5p-fimc/
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
From: "Luis R. Rodriguez"
spinlock_t should always be used.
Could not get this to build with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1
M=drivers/media/platform/s5p-jpeg
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
From: "Luis R. Rodriguez"
Turns out a few drivers have strayed away from using the
spinlock_t typedef and decided to use struct spinlock
directly. This series converts these drivers to use
spinlock_t. Each change has been compile tested with
allmodconfig and sparse checked. Driver deve
From: "Luis R. Rodriguez"
spinlock_t should always be used.
I was unable to build test with allmodconfig:
mcgrof@frijol ~/linux-next (git::(no branch))$ make C=1 M=drivers/crypto/ux500/
WARNING: Symbol version dump /home/mcgrof/linux-next/Module.symvers
is missing; mo
On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel wrote:
> So what is the rationale here. During mainlining our drivers we had to
> remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle
> (chapter 5 Typedefs) is spending a number of lines explaining why.
>
> So is spinlock_t an ex
On Fri, Nov 30, 2012 at 11:18 AM, Luis R. Rodriguez
wrote:
> On Fri, Nov 30, 2012 at 12:38 AM, Arend van Spriel wrote:
>> So what is the rationale here. During mainlining our drivers we had to
>> remove all uses of 'typedef struct foo foo_t;'. The Linux CodingStyle
&
From: "Luis R. Rodriguez"
This adds backport support for all media subsystem
drivers. This is enabled only for >= 3.2. Some media
drivers rely on the new probe deferrral mechanism
(-EPROBE_DEFER see commit d1c3414c), those are only
enabled for kernels >= 3.4. Some media driver
On Wed, Apr 9, 2014 at 9:14 AM, Antti Palosaari wrote:
> +extern struct dvb_frontend *rtl2832_sdr_attach(struct dvb_frontend *fe,
> + struct i2c_adapter *i2c, const struct rtl2832_config *cfg,
> + struct v4l2_subdev *sd);
Thanks for the patch! Joe has been going on a crusade to remov
On Wed, Apr 9, 2014 at 2:32 PM, Antti Palosaari wrote:
> +extern struct dvb_frontend *rtl2832_sdr_attach(struct dvb_frontend *fe,
> + struct i2c_adapter *i2c, const struct rtl2832_config *cfg,
> + struct v4l2_subdev *sd);
extern
Luis
--
To unsubscribe from this list: send the line
Couple of changes to help with backports, both to help with ensuring
drivers use their own namespace.
Luis R. Rodriguez (2):
technisat-usb2: rename led enums to be specific to driver
bt8xx: make driver routines fit into its own namespcae
drivers/media/pci/bt8xx/dst.c | 20
From: "Luis R. Rodriguez"
The current names clash with include/linux/leds.h namespace,
although there is no compile issue currently this does affect
backports. Drivers should also try to avoid generic namespaces
for things like this.
Cc: Mauro Carvalho Chehab
Cc: Felipe Pena
C
From: "Luis R. Rodriguez"
There is a few conflicts with older symbols on older kernels so we
have to patch this driver when backporting. Instead just make these
routines specific to the driver.
Cc: Mauro Carvalho Chehab
Cc: linux-media@vger.kernel.org
Signed-off-by: Luis R.
3 new linux backports release are now available based on linux-next
tags next-20140320 [0] next-20140411 [1] and next-20140417 [2]. This
should mean that we can keep things in synch now almost daily, and
drivers can be tested with the latest code as-is on linux-next. We've
shaved off kernel support
s net/ieee802154/ with make
backports: fix compilation with CONFIG_OF
backports: add crypto/ccm backport
Luis R. Rodriguez (25):
backports: backport ktime_to_ms()
backports: backport getrawmonotonic() with
do_posix_clock_monotonic_gettime()
backports: refres
Linux backports [0] backports-v3.15-rc1 is out [1]. Please
go test and see if you can and break things or if see if
we've broken anything so far before a final release in
sync with Linus' releases. As usual development only happens
on the master branch, we'll then carry fixes onto the stable
branch
Full kernel integration is now merged as part of Linux
backports-20141114. I've written a bit about it [0] [1], what we need
now are users and developer to give this a good spin as we wind down
for the v3.19 release, which will be the first release that will
support kernel integration down to any k
From: "Luis R. Rodriguez"
Sadly this driver requires a bit of work in order
to use ioremap_wc() on the range currently used
for MTRR write-combining. We'd need to ensure two
ioremap() calls are done. Annotate this.
Cc: Andy Lutomirski
Cc: Andy Walls
Cc: Suresh Siddha
Cc: Venk
usses overlapping ioremap() calls and what we'd need
for a default shift from UC- to strong UC.
On Fri, Apr 10, 2015 at 11:25:22PM -0700, Andy Lutomirski wrote:
> On Apr 10, 2015 6:29 PM, "Luis R. Rodriguez" wrote:
> >
> > On Fri, Apr 10, 2015 at 02:22:51PM -0700, Andy Lut
On Wed, Apr 15, 2015 at 01:42:47PM -0700, Andy Lutomirski wrote:
> On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez wrote:
>
> > c) ivtv: the driver does not have the PCI space mapped out separately, and
> > in fact it actually does not do the math for the framebuffer, in
Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
full range ioremap_wc() idea below.
On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
> Hi All,
>
> On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
> > From the beginning it seems o
On Thu, Apr 16, 2015 at 01:18:37PM +0900, Hyong-Youb Kim wrote:
> On Thu, Apr 16, 2015 at 01:58:16AM +0200, Luis R. Rodriguez wrote:
> >
> > An alternative... is to just ioremap_wc() the entire region, including
> > MMIO registers for these old devices. I see one ethe
On Wed, Apr 15, 2015 at 05:58:14PM -0700, Andy Lutomirski wrote:
> On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls wrote:
> > On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
> >> On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls
> >> wrote:
> >
> >> >
> >>
> >> IMO the right solution would be to
On Wed, Apr 15, 2015 at 09:07:37PM -0400, Andy Walls wrote:
> On Thu, 2015-04-16 at 01:58 +0200, Luis R. Rodriguez wrote:
> > Hey Andy, thanks for your review, adding Hyong-Youb Kim for review of the
> > full range ioremap_wc() idea below.
> >
> > On Wed, Apr 15, 201
On Tue, Apr 21, 2015 at 3:02 PM, Luis R. Rodriguez wrote:
> Andy, can we live without MTRR support on this driver for future kernels? This
> would only leave ipath as the only offending driver.
Sorry to be clear, can we live with removal of write-combining on this driver?
Luis
On Wed, Apr 15, 2015 at 01:42:47PM -0700, Andy Lutomirski wrote:
> On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez wrote:
>
> > c) ivtv: the driver does not have the PCI space mapped out separately, and
> > in fact it actually does not do the math for the framebuffer, in
On Tue, Apr 21, 2015 at 06:51:26PM -0400, Andy Walls wrote:
> Sorry for the top post; mobile work email account.
>
> Luis,
>
> You do the changes to remove MTTR and point me to your dev repo and branch.
> Also point me to the new functions/primitives I'll need.
There is nothing new actually need
On Tue, Apr 21, 2015 at 04:57:32PM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2015 at 12:46:01AM +0200, Luis R. Rodriguez wrote:
>
> > are talking about annotating the qib driver as "known to be broken without
> > PAT"
> > and since the ipath driver needs
On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
> > > Mike, do you think the time is right to just remove the iPath driver?
> >
> > With PAT now being default the driver effectively w
On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
> On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> > On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
> > > > Mike, do you think the time is right to just re
On Wed, Apr 22, 2015 at 8:54 AM, Luis R. Rodriguez wrote:
> On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
>> On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
>> > On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
>>
On Wed, Apr 22, 2015 at 10:17:55AM -0600, Jason Gunthorpe wrote:
> On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
> > On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> > > On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
>
On Wed, Apr 22, 2015 at 09:53:03AM -0700, Andy Lutomirski wrote:
> On Wed, Apr 22, 2015 at 8:23 AM, Luis R. Rodriguez wrote:
> > On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> >> On Wed, Apr 22, 2015 at 01:39:07AM +0200, Luis R. Rodriguez wrote:
> >>
On Wed, Apr 22, 2015 at 02:53:11PM -0400, Doug Ledford wrote:
> On Wed, 2015-04-22 at 10:17 -0600, Jason Gunthorpe wrote:
> > On Wed, Apr 22, 2015 at 05:23:28PM +0200, Luis R. Rodriguez wrote:
> > > On Tue, Apr 21, 2015 at 11:39:39PM -0600, Jason Gunthorpe wrote:
> > > &
On Wed, Apr 22, 2015 at 12:10 PM, Doug Ledford wrote:
> On Wed, 2015-04-22 at 21:05 +0200, Luis R. Rodriguez wrote:
>
>> > > I'd also love to remove the driver if it turns out there are actually
>> > > no users. qib substantially replaces it except for a few ver
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.
I
On Mon, Jun 23, 2014 at 06:41:28AM -0700, Joe Perches wrote:
> Adding the helper reduces object code size as well as overall
> source size line count.
>
> It's also consistent with all the various zalloc mechanisms
> in the kernel.
>
> Done with a simple cocci script and some typing.
Awesome, an
On Sat, Jul 19, 2014 at 9:19 AM, Hauke Mehrtens wrote:
> Maintaining the regulator drivers in backports costs some time and I do
> not need them. Is anybody using the regulator drivers from backports? I
> would like to remove them.
That came simply from collateral of backporting media drivers,
ev
On Wed, Jul 23, 2014 at 10:57 AM, Mauro Carvalho Chehab
wrote:
> Em Wed, 23 Jul 2014 10:13:28 -0700
> "Luis R. Rodriguez" escreveu:
>
>> On Sat, Jul 19, 2014 at 9:19 AM, Hauke Mehrtens wrote:
>> > Maintaining the regulator drivers in backports costs some ti
On Wed, Jul 23, 2014 at 11:56 AM, Hauke Mehrtens wrote:
> carrying some regularity drivers which are needed for some specific
> media driver does not look like a big problem. The current problem from
> my side is that we carry all regularity drivers by default and that
> causes some problems. Many
On Fri, Aug 29, 2014 at 09:19:42AM -0700, Jim Davis wrote:
> Building with the attached random configuration file,
>
> LD init/built-in.o
> drivers/built-in.o: In function `technisat_usb2_set_voltage':
> technisat-usb2.c:(.text+0x3b4919): undefined reference to `stv090x_set_gpio'
> make: **
93 matches
Mail list logo
