On Tue, Jan 23, 2024 at 11:56:42AM +0200, Sakari Ailus wrote:
> There are two ways to opportunistically increment a device's runtime PM
> usage count, calling either pm_runtime_get_if_active() or
> pm_runtime_get_if_in_use(). The former has an argument to tell whether to
> ignore the usage count
On Mon, Jan 22, 2024 at 08:50:59PM +0100, Duje Mihanović wrote:
> KTD2801 is a LED backlight driver IC found in samsung,coreprimevelte.
> The brightness can be set using PWM or the ExpressWire protocol. Add
> support for the KTD2801.
>
> Reviewed-by: Linus Walleij
> Signed-off-by: Duje Mihanović
On Mon, Jan 22, 2024 at 08:50:58PM +0100, Duje Mihanović wrote:
> KTD2801 is a LED backlight driver IC found in samsung,coreprimevelte.
> The brightness can be set using PWM or the ExpressWire protocol. Add
> a DT binding for the KTD2801.
>
> Reviewed-by: Krzysztof Kozlowski
> Reviewed-by: Linus
On Mon, Jan 22, 2024 at 08:50:57PM +0100, Duje Mihanović wrote:
> The ExpressWire protocol is shared between at least KTD2692 and KTD2801
> with slight differences such as timings and the former not having a
> defined set of pulses for enabling the protocol (possibly because it
> does not support
On Tue, 23 Jan 2024 17:29:12 +0100
Heiko Stübner wrote:
> Am Montag, 22. Januar 2024, 17:30:42 CET schrieb Boris Brezillon:
> > This is the last piece missing to expose the driver to the outside
> > world.
> >
> > This is basically a wrapper between the ioctls and the other logical
> > blocks.
On Mon, Jan 22, 2024 at 11:38:15AM +0100, AngeloGioacchino Del Regno wrote:
> Il 19/01/24 17:44, Conor Dooley ha scritto:
> > Rob,
> >
> > On Fri, Jan 19, 2024 at 02:32:22PM +0800, Jason-JH.Lin wrote:
> > > Add mediatek,gce-props.yaml for common GCE properties that is used for
> > > both mailbox
Am 19.01.24 um 23:14 schrieb Pavel Machek:
Hi!
And while I would personally hate it, you can imagine a use case where
you'd like a keypress to have a visual effect around the key you
pressed. A kind of force feedback, if you will. I don't actually know,
and correct me if I'm wrong, but feels
Am Montag, 22. Januar 2024, 17:30:42 CET schrieb Boris Brezillon:
> This is the last piece missing to expose the driver to the outside
> world.
>
> This is basically a wrapper between the ioctls and the other logical
> blocks.
>
> v4:
> - Add an ioctl to let the UMD query the VM state
> - Fix
Am Montag, 22. Januar 2024, 17:30:31 CET schrieb Boris Brezillon:
> Hello,
>
> This is the 4th version of the kernel driver for Mali CSF-based GPUs.
>
> A branch based on drm-misc-next and containing all the dependencies
> that are not yet available in drm-misc-next here[1], and another [2]
>
Hello Sui,
On Tue, Jan 23, 2024 at 08:18:22PM +0800, Sui Jingfeng wrote:
> On 2024/1/23 09:18, Laurent Pinchart wrote:
> > On Tue, Jan 23, 2024 at 12:32:18AM +0800, Sui Jingfeng wrote:
> >> Which make it possible to use this driver on non-DT based systems,
> >> meanwhile, made no functional
On Tue, Jan 23, 2024 at 04:20:04PM +0800, Sui Jingfeng wrote:
> On 2024/1/23 09:21, Laurent Pinchart wrote:
> > On Tue, Jan 23, 2024 at 12:32:17AM +0800, Sui Jingfeng wrote:
> >> Which is intended to be used on non-DT environment, where the simple-bridge
> >> platform device is created by either
Hi Sui,
On Tue, Jan 23, 2024 at 04:01:28PM +0800, Sui Jingfeng wrote:
> On 2024/1/23 09:17, Laurent Pinchart wrote:
> > On Tue, Jan 23, 2024 at 12:32:16AM +0800, Sui Jingfeng wrote:
> >> Because ACPI based systems only has the fwnode associated, the of_node
> >> member of struct device is NULL.
On 23/01/2024 13:56, Thomas Zimmermann wrote:
Hi,
FYI for points 1 and 2, I'm typing up a patchset that introduces
drm_pixmap for the source buffer. I'll post it when I have something ready.
Thanks, I didn't have time to look into this yet.
Best regards,
--
Jocelyn
Best regards
On Tue, 23 Jan 2024, Thomas Zimmermann wrote:
> This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4.
>
> Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
> device_initcall to subsys_initcall_sync") messes up initialization order
> of the graphics drivers and leads to
On Tue, 23 Jan 2024 10:43:04 +0100
Christian König wrote:
> While applying the fix a week ago I was under the impression that QXL
> doesn't use a device structure because it doesn't have one and so can't
> give anything meaningful for this parameter.
>
> If QXL does have a device structure
On Tue, Jan 23, 2024, at 12:45, Geert Uytterhoeven wrote:
>> 68 error regressions:
>
>> + /kisskb/src/arch/powerpc/sysdev/udbg_memcons.c: error: no previous
>> prototype for 'memcons_getc' [-Werror=missing-prototypes]: => 80:5
>> + /kisskb/src/arch/powerpc/sysdev/udbg_memcons.c: error: no
Thomas Zimmermann writes:
> This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4.
>
> Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
> device_initcall to subsys_initcall_sync") messes up initialization order
> of the graphics drivers and leads to blank displays on
Am 23.01.24 um 14:02 schrieb Paul Cercueil:
[SNIP]
That an exporter has to call extra functions to access his own
buffers
is a complete no-go for the design since this forces exporters
into
doing extra steps for allowing importers to access their data.
Then what about we add these
Hi
Am 23.01.24 um 14:12 schrieb Huacai Chen:
I'm very sorry to hear that, If Jaak can respond, I think I can find
the root cause and fix that...
No problem, don't worry. We wanted to revert that patch anyway. And the
*real* fix here is to track the framebuffer ownership more closely.
Best
I'm very sorry to hear that, If Jaak can respond, I think I can find
the root cause and fix that...
Huacai
On Tue, Jan 23, 2024 at 8:09 PM Thomas Zimmermann wrote:
>
> This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4.
>
> Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init()
Hi,
CCing Li Chao
On 2024/1/21 15:07, Katyusha wrote:
Hi,
On 2024/1/21 5:28, Sui JIngfeng wrote:
Hi,
On 2024/1/20 20:01, Katyusha wrote:
Hi,
This patch works fine with my Loongson 3A5000M laptop (L71), which
has a 7A1000 chipset without VRAM.
Can you give more details about the
From: Donald Robson
When the kernel driver 'loses' the device, for instance if the firmware
stops communicating, the driver calls drm_dev_unplug(). This is
currently done inside the drm_dev_enter() critical section, which isn't
permitted. In addition, the bool that marks the device as lost is
Le mardi 23 janvier 2024 à 12:52 +0100, Christian König a écrit :
> Am 23.01.24 um 11:10 schrieb Paul Cercueil:
> > Hi Christian,
> >
> > Le lundi 22 janvier 2024 à 14:41 +0100, Christian König a écrit :
> > > Am 22.01.24 um 12:01 schrieb Paul Cercueil:
> > > > Hi Christian,
> > > >
> > > > Le
Hi,
FYI for points 1 and 2, I'm typing up a patchset that introduces
drm_pixmap for the source buffer. I'll post it when I have something ready.
Best regards
Thomas
Am 19.01.24 um 11:58 schrieb Thomas Zimmermann:
Hi
Am 17.01.24 um 17:40 schrieb Jocelyn Falempe:
On 17/01/2024 16:06,
Hi,
On 2024/1/23 09:20, Laurent Pinchart wrote:
On Tue, Jan 23, 2024 at 12:32:20AM +0800, Sui Jingfeng wrote:
From: Sui Jingfeng
Because API has wider coverage, it can be used on non-DT systems as well.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/bridge/display-connector.c | 22
Hi,
On 2024/1/23 09:21, Laurent Pinchart wrote:
static int simple_bridge_probe(struct platform_device *pdev)
{
struct simple_bridge *sbridge;
@@ -176,7 +194,10 @@ static int simple_bridge_probe(struct platform_device
*pdev)
return -ENOMEM;
Hi,
On 2024/1/23 09:18, Laurent Pinchart wrote:
On Tue, Jan 23, 2024 at 12:32:18AM +0800, Sui Jingfeng wrote:
Which make it possible to use this driver on non-DT based systems,
meanwhile, made no functional changes for DT based systems.
Signed-off-by: Sui Jingfeng
---
This reverts commit 60aebc9559492cea6a9625f514a8041717e3a2e4.
Commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
device_initcall to subsys_initcall_sync") messes up initialization order
of the graphics drivers and leads to blank displays on some systems. So
revert the commit.
To
On Wed, 03 Jan 2024 15:31:06 +0200, Tomi Valkeinen wrote:
> Two small fixes to sii902x for crashes.
>
>
Applied, thanks!
[1/2] drm/bridge: sii902x: Fix probing race issue
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=dffdfb8f5de1
[2/2] drm/bridge: sii902x: Fix audio codec
Am 23.01.24 um 11:10 schrieb Paul Cercueil:
Hi Christian,
Le lundi 22 janvier 2024 à 14:41 +0100, Christian König a écrit :
Am 22.01.24 um 12:01 schrieb Paul Cercueil:
Hi Christian,
Le lundi 22 janvier 2024 à 11:35 +0100, Christian König a écrit :
Am 19.01.24 um 15:13 schrieb Paul Cercueil:
On Tue, 23 Jan 2024, Geert Uytterhoeven wrote:
Below is the list of build error/warning regressions/improvements in
v6.8-rc1[1] compared to v6.7[2].
Summarized:
- build errors: +68/-18
- build warnings: +129/-1487
Happy fixing! ;-)
Thanks to the linux-next team for providing the build
Am 23.01.24 um 09:33 schrieb Zhou, Xianrong:
[AMD Official Use Only - General]
The vmf_insert_pfn_prot could cause unnecessary double faults on a
device pfn. Because currently the vmf_insert_pfn_prot does not make
the pfn writable so the pte entry is normally read-only or dirty
catching.
Hi,
This patch works fine with my Loongson 3A5000 laptop (GDC-1401), which
has a
7A1000 chipset without VRAM.
lspci |grep VGA
00:06.1 VGA compatible controller: Loongson Technology LLC DC (Display
Controller) (rev 01)
07:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI]
On Thu, 18 Jan 2024 23:02:31 +0100, Marek Vasut wrote:
> According to new configuration spreadsheet from Toshiba for TC9595,
> the Pixel PLL input clock have to be in range 6..40 MHz. The sheet
> calculates those PLL input clock as reference clock divided by both
> pre-dividers. Add the extra
Hi Oak,
Am 23.01.24 um 04:21 schrieb Zeng, Oak:
Hi Danilo and all,
During the work of Intel's SVM code, we came up the idea of making drm_gpuvm to
work across multiple gpu devices. See some discussion here:
Hi Rodrigo,
Thank you for review.
On Monday, 22 January 2024 22:09:38 CET Rodrigo Vivi wrote:
> On Mon, Jan 22, 2024 at 03:04:42PM +0100, Janusz Krzysztofik wrote:
> > Object debugging tools were sporadically reporting illegal attempts to
> > free a still active i915 VMA object when parking a
Detect DP tunnels and enable the BW allocation mode on them. Send a
hotplug notification to userspace in response to a BW change.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_driver.c | 20 +++
drivers/gpu/drm/i915/display/intel_dp.c | 14 +++--
Handle DP tunnel IRQs a sink (or rather a BW management component like
the Thunderbolt Connection Manager) raises to signal the completion of a
BW request by the driver, or to signal any state change related to the
link BW.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c |
Suspend and resume DP tunnels during system suspend/resume, disabling
the BW allocation mode during suspend, re-enabling it after resume. This
reflects the link's BW management component (Thunderbolt CM) disabling
BWA during suspend. Before any BW requests the driver must read the
sink's DPRX
Take any link BW limitation into account in
intel_dp_max_link_data_rate(). Such a limitation can be due to multiple
displays on (Thunderbolt) links with DP tunnels sharing the link BW.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 32 +
1 file
Add the atomic state during a modeset required to enable the DP tunnel
BW allocation mode on links where such a tunnel was detected.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_atomic.c | 8
drivers/gpu/drm/i915/display/intel_display.c | 19 +++
Allocate and free the DP tunnel BW required by a stream while
enabling/disabling the stream during a modeset.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/g4x_dp.c| 28
drivers/gpu/drm/i915/display/intel_ddi.c | 7 ++
2 files changed, 35
A follow-up change will need to resume DP tunnels during system resume,
so call intel_dp_sync_state() always for DDI encoders, so this function
can resume the tunnels for all DP connectors.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
1 file changed, 1
Add intel_dp_max_link_data_rate() to get the link BW vs. the sink DPRX
BW used by a follow-up patch enabling the DP tunnel BW allocation mode.
The link BW can be below the DPRX BW due to a BW limitation on a link
shared by multiple sinks.
Signed-off-by: Imre Deak
---
Factor out a function updating the sink's link rate and lane count
capabilities, used by a follow-up patch enabling the DP tunnel BW
allocation mode.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 11 ---
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
2 files
Compute the BW required through a DP tunnel on links with such tunnels
detected and add the corresponding atomic state during a modeset.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 16 +---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 13 +
Add a way to get the active pipes through a given DP port by syncing
against a related pending non-blocking commit. Atm
intel_dp_get_active_pipes() will only try to sync a given pipe and if
that would block ignore the pipe. A follow-up change enabling the DP
tunnel BW allocation mode will need to
Add support to enable the DP tunnel BW allocation mode. Follow-up
patches will call the required helpers added here to prepare for a
modeset on a link with DP tunnels, the last change in the patchset
actually enabling BWA.
With BWA enabled, the driver will expose the full mode list a display
Instead of intel_dp_max_data_rate() use the equivalent
drm_dp_max_dprx_data_rate() which was copied from the former one in a
previous patch.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 62 +++-
Add support for Display Port DP tunneling. For now this includes the
support for Bandwidth Allocation Mode, leaving adding Panel Replay
support for later.
BWA allows using displays that share the same (Thunderbolt) link with
their maximum resolution. Atm, this may not be possible due to the
Export intel_dp_max_common_rate() and intel_dp_max_lane_count() used by
a follow-up patch enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/display/intel_dp.h | 2 ++
2 files changed, 4 insertions(+), 2
Factor out a function to read the sink's DPRX capabilities used by a
follow-up patch enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_dp_link_training.c | 30 +++
.../drm/i915/display/intel_dp_link_training.h | 1 +
2 files
Factor out intel_dp_config_required_rate() used by a follow-up patch
enabling the DP tunnel BW allocation mode.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_dp.c | 43 +++--
drivers/gpu/drm/i915/display/intel_dp.h | 1 +
2 files changed, 20 insertions(+),
On shared (Thunderbolt) links with DP tunnels, the modeset may need to
be retried on all connectors on the link due to a link BW limitation
arising only after the atomic check phase. To support this add a helper
function queuing a work to retry the modeset on a given port's connector
and at the
Copy intel_dp_max_data_rate() to DRM core. It will be needed by a
follow-up DP tunnel patch, checking the maximum rate the DPRX (sink)
supports. Accordingly use the drm_dp_max_dprx_data_rate() name for
clarity. This patchset will also switch calling the new DRM function
in i915 instead of
Add support for detecting DP tunnels on (Thunderbolt) display links and
enabling the Bandwidth Allocation mode on the link. This helps in
enabling the maximum resolution in any scenario on displays sharing the
BW on such links.
Kudos to all Cc'd for advices, co-development and testing.
Cc: Mika
Forgot to add a few changes to the changelog:
On Tue, 2024-01-23 at 10:42 +0100, Philipp Stanner wrote:
> Changes in v2:
> - Make commit head lines congruent with PCI's style (Bjorn)
> - Add missing error checks for devm_add_action(). (Andy)
> - Repair the "Returns: " marks for docu
Hello Felix Kuehling,
The patch 1819200166ce: "drm/amdkfd: Export DMABufs from KFD using
GEM handles" from Aug 24, 2023 (linux-next), leads to the following
Smatch static checker warning:
drivers/dma-buf/dma-buf.c:729 dma_buf_get()
warn: fd used after fd_install() 'fd'
Hi
Am 23.01.24 um 10:41 schrieb Javier Martinez Canillas:
Thorsten Leemhuis writes:
On 23.01.24 09:53, Jani Nikula wrote:
On Wed, 08 Nov 2023, Thomas Zimmermann wrote:
[...]
As you know, there's a platform device that represents the firmware
framebuffer. The firmware drivers, such as
Stop offering pm_runtime_get_if_conditional() API function for drivers,
instead require them to use pm_runtime_get_if_{active,in_use}. Also
convert the only user, the i915 driver, to use the said functions.
Signed-off-by: Sakari Ailus
---
drivers/base/power/runtime.c| 34
Hi Christian,
Le lundi 22 janvier 2024 à 14:41 +0100, Christian König a écrit :
> Am 22.01.24 um 12:01 schrieb Paul Cercueil:
> > Hi Christian,
> >
> > Le lundi 22 janvier 2024 à 11:35 +0100, Christian König a écrit :
> > > Am 19.01.24 um 15:13 schrieb Paul Cercueil:
> > > > These functions
There are two ways to opportunistically increment a device's runtime PM
usage count, calling either pm_runtime_get_if_active() or
pm_runtime_get_if_in_use(). The former has an argument to tell whether to
ignore the usage count or not, and the latter simply calls the former with
ign_usage_count set
Hi folks,
Here's a small but a different set of patches for making two relatively
minor changes to runtime PM API. I restarted version numbering as this is
meaningfully different from the previous set.
pm_runtime_get_if_active() loses its second argument as it only made sense
to have
Managing pci_set_mwi() with devres can easily be done with its own
callback, without the necessity to store any state about it in a
device-related struct.
Remove the MWI state from struct pci_devres.
Give pcim_set_mwi() a separate devres-callback.
Signed-off-by: Philipp Stanner
---
The bit describing whether the PCI device is currently enabled is stored
in struct pci_devres. Besides this struct being subject of a cleanup
process, struct pci_device is in general the right place to store this
information, since it is not devres-specific.
Move the 'enabled' boolean bit to
Thanks to preceding cleanup steps, pcim_release() is now not needed
anymore and can be replaced by pcim_disable_device(), which is the exact
counterpart to pcim_enable_device().
This permits removing further parts of the old devres API.
Replace pcim_release() with pcim_disable_device().
Remove
Now that pure managed region request functions are available, the
implementation of the hybrid-functions which are only sometimes managed
can be made more consistent and readable by wrapping those
always-managed functions.
Implement a new pcim_ function for exclusively requested regions.
Have the
When the PCI devres API was introduced to this driver, it was wrongly
assumed that initializing the device with pcim_enable_device() instead
of pci_enable_device() will make all PCI functions managed.
This is wrong and was caused by the quite confusing devres API for PCI
in which some, but not
pci_intx() is one of the functions that have "hybrid mode" (i.e.,
sometimes managed, sometimes not). Providing a separate pcim_intx()
function with its own device resource and cleanup callback allows for
removing further large parts of the legacy pci-devres implementation.
As in the
On 23.01.24 10:17, Thorsten Leemhuis wrote:
> On 23.01.24 09:53, Jani Nikula wrote:
>> On Wed, 08 Nov 2023, Thomas Zimmermann wrote:
>>>
>>> thanks for the patch.
>>>
>>> Am 08.11.23 um 03:46 schrieb Huacai Chen:
After commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
The bit describing whether the PCI device is currently pinned is stored
in struct pci_devres. To clean up and simplify the PCI devres API, it's
better if this information is stored in struct pci_dev, because it
allows for checking that device's pinned-status directly through
struct pci_dev.
This
The PCI region-request functions become managed functions when
pcim_enable_device() has been called previously instead of
pci_enable_device().
This has already caused bugs by confusing users, who came to believe
that all pci functions, such as pci_iomap_range(), suddenly are managed
that way.
The old plural devres functions tie the PCI devres API to the
iomap-table mechanism which unfortunately is not extensible.
As the purlal functions are almost never used with more than one bit set
in their bit-mask, deprecating them and encouraging users to use the new
singular functions instead
The PCI devres API is not extensible to partial BAR mappings and has
bug-provoking features. Improve that by providing better alternatives.
When the original PCI devres API was implemented, priority was given to
the creation of a set of "plural functions" such as
pcim_request_regions(). These
Changes in v2:
- Make commit head lines congruent with PCI's style (Bjorn)
- Add missing error checks for devm_add_action(). (Andy)
- Repair the "Returns: " marks for docu generation (Andy)
- Initialize the addr_devres struct with memset(). (Andy)
- Make pcim_intx() a PCI-internal
Am 23.01.24 um 03:52 schrieb Steven Rostedt:
On Tue, 23 Jan 2024 12:32:39 +1000
Dave Airlie wrote:
On Tue, 23 Jan 2024 at 12:21, Dave Airlie wrote:
On Tue, 23 Jan 2024 at 12:15, Steven Rostedt wrote:
On Mon, 22 Jan 2024 19:56:08 -0500
"Bhardwaj, Rajneesh" wrote:
On 1/22/2024 7:43 PM,
Thorsten Leemhuis writes:
> On 23.01.24 09:53, Jani Nikula wrote:
>> On Wed, 08 Nov 2023, Thomas Zimmermann wrote:
[...]
>
>>> As you know, there's a platform device that represents the firmware
>>> framebuffer. The firmware drivers, such as simpledrm, bind to it. In
>>> i915 and the other
On 23.01.24 09:53, Jani Nikula wrote:
> On Wed, 08 Nov 2023, Thomas Zimmermann wrote:
>>
>> thanks for the patch.
>>
>> Am 08.11.23 um 03:46 schrieb Huacai Chen:
>>> After commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
>>> device_initcall to subsys_initcall_sync") some Lenovo
Hi
Am 18.01.24 um 15:17 schrieb Daniel Vetter:
On Thu, Jan 18, 2024 at 10:05:25AM +0100, Thomas Zimmermann wrote:
Replace CONFIG_VIDEO_CMDLINE and CONFIG_VIDEO_NOMODESET by the single
option CONFIG_VIDEO. Select the latter for DRM or fbdev. Both original
options used to be selected in most
Let's CC Felix on this one because he might know the answer.
All day long I spend looking at code like this:
net/core/dev.c:724 dev_fill_forward_path() info: returning a literal zero is
cleaner
net/core/dev.c:732 dev_fill_forward_path() info: returning a literal zero is
cleaner
net/core/dev.c
On Wed, 08 Nov 2023, Thomas Zimmermann wrote:
> Hi,
>
> thanks for the patch.
>
> Am 08.11.23 um 03:46 schrieb Huacai Chen:
>> After commit 60aebc9559492cea ("drivers/firmware: Move sysfb_init() from
>> device_initcall to subsys_initcall_sync") some Lenovo laptops get a blank
>> screen until the
[AMD Official Use Only - General]
> > The vmf_insert_pfn_prot could cause unnecessary double faults on a
> > device pfn. Because currently the vmf_insert_pfn_prot does not make
> > the pfn writable so the pte entry is normally read-only or dirty
> > catching.
>
> What? How do you got to this
Hi,
On 16/01/2024 15:41, Devarsh Thakkar wrote:
This overlay needs to be used with display sharing supported device
manager firmware only.
Remote core running this firmware has write access to "common" register
space, VIDL pipeline, OVR1 overlay and VP1 videoport.
The processing core running
Hi Krzysztof,
On 22/01/24 9:19 pm, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> On 22/01/2024 09:29, Dharma Balasubiramani wrote:
>> Add a new LVDS controller driver for sam9x7 which does the following:
>> -
Hi,
On 16/01/2024 15:41, Devarsh Thakkar wrote:
Display subsystem present in TI Keystone family of devices supports sharing
of display between multiple hosts as it provides separate register space
(common* region) for each host to programming display controller and also a
unique interrupt line
Hi,
On 2024/1/23 09:21, Laurent Pinchart wrote:
On Tue, Jan 23, 2024 at 12:32:17AM +0800, Sui Jingfeng wrote:
Which is intended to be used on non-DT environment, where the simple-bridge
platform device is created by either the display controller driver side or
platform firmware subsystem.
Hi,
Thanks a lot for your review :-)
On 2024/1/23 09:17, Laurent Pinchart wrote:
Hi Sui,
Thank you for the patch.
On Tue, Jan 23, 2024 at 12:32:16AM +0800, Sui Jingfeng wrote:
Because ACPI based systems only has the fwnode associated, the of_node
member of struct device is NULL. To order
101 - 188 of 188 matches
Mail list logo
