On Tue, 2025-04-08 at 16:30 +, Timur Tabi wrote:
> On Tue, 2025-04-08 at 17:21 +0100, David Woodhouse wrote:
> > If I set the BIOS to use the external display at boot time, that works
> > and Linux starts booting using the USB-C monitor — until nouveau inits,
> > at
On Tue, 2025-04-08 at 16:46 +, Timur Tabi wrote:
> On Tue, 2025-04-08 at 17:42 +0100, David Woodhouse wrote:
> > ISTR you said that if the proprietary driver does manage to use that
> > port, then we could at least look at why nouveau doesn't?
>
> Yes, but that
On Tue, 2025-04-08 at 15:59 +, Timur Tabi wrote:
> On Mon, 2025-04-07 at 21:09 +0100, David Woodhouse wrote:
> > It *was* working, as long as I could tolerate it being scaled to 200% like
> > the internal display. It *did* light up the external display just fine.
>
> Ok,
On Mon, 2025-04-07 at 18:47 +, Timur Tabi wrote:
> On Mon, 2025-04-07 at 19:39 +0100, David Woodhouse wrote:
> > I'd already upgraded to 6.14, and have just rebooted into 6.14.1 with
> > that option enabled. I now have the four files in debugfs of which you
> > s
On 7 April 2025 20:51:50 BST, Timur Tabi wrote:
>On Mon, 2025-04-07 at 20:41 +0100, David Woodhouse wrote:
>> Yes. The proprietary driver (570.133.07) did manage to light up the
>> external monitor over USB-C/DP.
>>
>> It was utterly unusable, as I couldn'
On Mon, 2025-04-07 at 18:47 +, Timur Tabi wrote:
>
> Have you tried the proprietary driver? With Ada GPUs like yours, Nouveau
> just uses GSP-RM to do most of the GPU work. GSP-RM is just the Nvidia
> proprietary driver ported to RISC-V, and Nouveau basically does the same
> thing that our o
On Mon, 2025-04-07 at 18:30 +, Timur Tabi wrote:
> On Mon, 2025-04-07 at 17:14 +, Timur Tabi wrote:
> > What I need now are the GSP-RM logs. In your /etc/modprobe.d, see if
> > there
> > is a file with "options nouveau". If there isn't, create one, and then
> > add
> > the "keep-gsp-loggi
On Mon, 2025-04-07 at 16:28 +, Timur Tabi wrote:
> On Mon, 2025-04-07 at 16:28 +0100, David Woodhouse wrote:
> > [608593.5728743 CPU: 15 UID: 626640614 PID: 17529 Comm: WebKitWebProces
> > Taint
> > [608593.576062] Tainted: [W]=WARN
>
> What does this mean?
I have a Thinkpad P1 Gen6 with combined Intel + NVIDIA graphics:
00:02.0 VGA compatible controller [0300]: Intel Corporation Raptor Lake-P [Iris
Xe Graphics] [8086:a7a0] (rev 04)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD107GLM [RTX 2000
Ada Generation Laptop GPU] [10de:28b8
On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 18:07:04 +0100
> David Woodhouse escreveu:
>
> > On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > > Such conversion tools - plus some text editor like LibreOffice o
On Wed, 2021-05-12 at 17:17 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 10:14:44 -0400
> "Theodore Ts'o" escreveu:
>
> > On Wed, May 12, 2021 at 02:50:04PM +0200, Mauro Carvalho Chehab wrote:
> > > v2:
> > > - removed EM/EN DASH conversion from this patchset;
> >
> > Are you stil
Your title 'Use ASCII subset' is now at least a bit *closer* to
describing what the patches are actually doing, but it's still a bit
misleading because you're only doing it for *some* characters.
And the wording is still indicative of a fundamentally *misguided*
motivation for doing any of this. Y
On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
>
> - it helps people needing to touch the documents using non-utf8 locales[1];
> - it makes easier to grep for a text;
>
> [1] There are still some widely used distros nowadays (LT
On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8.
>
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specifi
On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
>
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used
On Tue, 2021-01-05 at 16:40 +0100, Christian König wrote:
> Am 05.01.21 um 13:20 schrieb Huang Rui:
> > On Tue, Jan 05, 2021 at 07:43:51PM +0800, Borislav Petkov wrote:
> > > On Tue, Jan 05, 2021 at 07:08:52PM +0800, Huang Rui wrote:
> > > > Ah, this asic is a bit old and still use radeon driver. S
From: David Woodhouse
This isn't needed in dtsi files.
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/mt7623a.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index 0735a1fb8ad9..a96075206cce 100644
--- a/arc
From: David Woodhouse
Based on a patch in OpenWrt from Kristian Evensen
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/mt7623a-unielec-u7623-emmc.dts | 347 ++
2 files changed, 348 insertions(+)
create mode 100644
From: David Woodhouse
The MT7623A doesn't have a GPU; add it only for MT7623N boards.
Fixes: 1f6ed224594 ("arm: dts: mt7623: add Mali-450 device node")
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/mt7623.dtsi | 24 -
arch/arm/boot/dts/mt762
On Wed, 2020-08-05 at 10:49 +0200, Frank Wunderlich wrote:
> > Gesendet: Mittwoch, 05. August 2020 um 10:36 Uhr
> > Von: "David Woodhouse"
> > > mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> > > mt7623.dtsi => mt7623a.dtsi =&g
On Wed, 2020-08-05 at 09:27 +0200, Frank Wunderlich wrote:
> or should we split dtsi to have a common part (mt7623.dtsi), and one for
> soc (mt7623n.dtsi/mt7623a.dtsi)?
>
> mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not ex
On Tue, 2020-08-04 at 19:40 +0200, Frank Wunderlich wrote:
> > Gesendet: Dienstag, 04. August 2020 um 19:24 Uhr
> > Von: "David Woodhouse"
> > > + mipi_tx0: mipi-dphy@1001 {
> > > + compatible = "mediatek,mt7623-mipi-tx",
>
On Tue, 2020-08-04 at 18:55 +0200, Frank Wunderlich wrote:
> From: Ryder Lee
>
> Add display subsystem related device nodes for MT7623.
>
> Cc: CK Hu
> Signed-off-by: chunhui dai
> Signed-off-by: Bibby Hsieh
> Signed-off-by: Ryder Lee
> Signed-off-by: Frank Wunderlich
> Tested-by: Frank Wun
On Fri, 2018-02-16 at 10:43 +0100, Norbert Manthey wrote:
> The current implementation will leak a byte to the log via memmove. The
> specified 27 bytes are off-by-one, as the payload is 25 bytes, and the
> termination character is only one byte large. To avoid this, factor out
> the error messag
On Mon, 2015-10-19 at 16:43 +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 19, 2015 at 04:29:40PM +0100, David Woodhouse wrote:
> > I don't know that there *is* a coherent plan here to address it
> > all.
> >
> > Certainly, we *will* need subsystems to have
On Mon, 2015-10-19 at 15:50 +0100, Mark Brown wrote:
> > But the point I'm making is that we are working towards *fixing* that,
> > and *not* using DT-specific code in places where we should be using the
> > generic APIs.
>
> What is the plan for fixing things here? It's not obvious (at least to
On Mon, 2015-10-19 at 07:35 -0500, Rob Herring wrote:
>
> > Certainly, if it literally is adding of_* calls then that would seem to
> > be gratuitously firmware-specific. Nothing should be using those these
> > days; any new code should be using the generic device property APIs
> > (except in spec
On Sun, 2015-10-18 at 20:53 +0100, Mark Brown wrote:
> On Sun, Oct 18, 2015 at 12:37:57PM -0700, Greg Kroah-Hartman wrote:
> > On Sun, Oct 18, 2015 at 08:29:31PM +0100, Mark Brown wrote:
> > > On Fri, Oct 16, 2015 at 11:57:50PM -0700, Greg Kroah-Hartman wrote:
>
> > > > I can't see adding calls li
.org/msg33138.html
> Cc: stable at vger.kernel.org
> Cc: David Woodhouse
> Reported-and-tested-by: Mihai Moldovan
> Signed-off-by: Daniel Vetter
> ---
> drivers/iommu/intel-iommu.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/driv
msg33138.html
> Cc: sta...@vger.kernel.org
> Cc: David Woodhouse
> Reported-and-tested-by: Mihai Moldovan
> Signed-off-by: Daniel Vetter
> ---
> drivers/iommu/intel-iommu.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iomm
On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> So don't bother, but instead disable it by default to allow distros to
> unconditionally enable DMAR support.
Acked-By: David Woodhouse
It *really* wi
On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> So don't bother, but instead disable it by default to allow distros to
> unconditionally enable DMAR support.
Acked-By: David Woodhouse
It *really* wi
On Fri, 2012-09-14 at 14:48 +0100, Matthew Garrett wrote:
> On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote:
>
> > Tested on MacbookPro8,3. Without this patch both the intel_backlight and
> > gmux_backlight devices get registered and userspace doesn't know which
> > it should use.
>
On Fri, 2012-09-14 at 14:09 +0100, Grant Likely wrote:
> On Fri, Sep 14, 2012 at 2:01 PM, Chris Wilson
> wrote:
> > On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely > secretlab.ca> wrote:
> >> Some platforms (for instance MacbookPros) have custom backlight drivers
> >> and don't use the integrat
On Fri, 2012-09-14 at 14:48 +0100, Matthew Garrett wrote:
> On Fri, Sep 14, 2012 at 01:57:06PM +0100, Grant Likely wrote:
>
> > Tested on MacbookPro8,3. Without this patch both the intel_backlight and
> > gmux_backlight devices get registered and userspace doesn't know which
> > it should use.
>
On Fri, 2012-09-14 at 14:09 +0100, Grant Likely wrote:
> On Fri, Sep 14, 2012 at 2:01 PM, Chris Wilson
> wrote:
> > On Fri, 14 Sep 2012 13:57:06 +0100, Grant Likely
> > wrote:
> >> Some platforms (for instance MacbookPros) have custom backlight drivers
> >> and don't use the integrated i915 bac
On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
> Those are needed by the rc6 and semaphores support in i915 driver.
>
> In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
> is enabled. So we use those variables to check the io remapping and iommu
> status.
This i
On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> Hm, that comment confuses me a bit. I've always thought that igfx_off only
> instantiates a identity mapping and leaves the dmar unit on. Is that
> wrong?
It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the on
On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
>
> Things I've tried that don't work around the issue:
> - Disable dmar for the igfx with intel_iommu=igfx_off
> - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
> idling while flushing).
Well, the ILK workaround was only
On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> for the dmar+rc6 hangs reported.
Um... let me restate that for clarity (and partly for
On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett
> > wrote:
> >
> > > So the user has to choose between 5W of power saving or having dmar? And
> > > we default to givi
On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
> Those are needed by the rc6 and semaphores support in i915 driver.
>
> In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
> is enabled. So we use those variables to check the io remapping and iommu
> status.
This i
On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> Hm, that comment confuses me a bit. I've always thought that igfx_off only
> instantiates a identity mapping and leaves the dmar unit on. Is that
> wrong?
It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the on
On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
>
> Things I've tried that don't work around the issue:
> - Disable dmar for the igfx with intel_iommu=igfx_off
> - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
> idling while flushing).
Well, the ILK workaround was only
On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> for the dmar+rc6 hangs reported.
Um... let me restate that for clarity (and partly for
On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
> >
> > > So the user has to choose between 5W of power saving or having dmar? And
> > > we default to giving th
lear_inode() is the file system's ->clear_inode method, so it
gets called from the VFS when the inode is destroyed, after iput().
I suppose that ought to have been a clue, right from the very beginning,
that we should never have been calling it directly on our e
he menu nesting, introduced with
the SmartMedia support. That one is a regression.
I'll concede that I could probably have lived without the DocBook patch,
and the patch to use memdup_user() in mtdchar.c, but they're so trivial
that it seemed pointless rebasing the tree to exclude them o
lear_inode() is the file system's ->clear_inode method, so it
gets called from the VFS when the inode is destroyed, after iput().
I suppose that ought to have been a clue, right from the very beginning,
that we should never have been calling it directly on our e
he menu nesting, introduced with
the SmartMedia support. That one is a regression.
I'll concede that I could probably have lived without the DocBook patch,
and the patch to use memdup_user() in mtdchar.c, but they're so trivial
that it seemed pointless rebasing the tree to exclude them once I
concluded I should to try my luck at getting the other stuff into -rc2.
--
David WoodhouseOpen Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
50 matches
Mail list logo
