Il 11/06/24 08:48, CK Hu (胡俊光) ha scritto:
On Mon, 2024-06-10 at 10:28 +0200, AngeloGioacchino Del Regno wrote:
Il 06/06/24 07:29, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
On Wed, 2024-06-05 at 13:15 +0200, AngeloGioacchino Del Regno wrote:
Il 05/06/24 03:38, CK Hu (胡俊光) ha scritto:
Hi, Angelo:
Hello,
kernel test robot noticed "WARNING:at_drivers/pinctrl/core.c:#devm_pinctrl_put"
on:
commit: ce2701911ab8b371b9a93b6f9482f0577729d8aa ("[PATCH]
drivers/base/devres.c: refactor using guards")
url:
https://github.com/intel-lab-lkp/linux/commits/Andrea-Calabrese/drivers-base-devres-c-ref
https://bugzilla.kernel.org/show_bug.cgi?id=211807
Felix Andrea (felixandre...@gmail.com) changed:
What|Removed |Added
CC||felixandre...@gma
> Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start
>
> Hi
>
> Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
> > From: Peng Fan
> >
> > If 'info->screen_buffer' locates in vmalloc address space,
> > virt_to_page will not be able to get correct results. With
> > CONFIG_DEBUG_VM and CONFIG
On Mon, Jun 10, 2024 at 08:20:08PM +0100, Pavel Begunkov wrote:
> On 6/10/24 16:16, David Ahern wrote:
> > > There is no reason you shouldn't be able to use your fast io_uring
> > > completion and lifecycle flow with DMABUF backed memory. Those are not
> > > widly different things and there is goo
On Fri, Jun 7, 2024 at 5:29 PM Linux regression tracking (Thorsten
Leemhuis) wrote:
>
> [CCing the other amd drm maintainers]
>
> Mikhail: are those details in any way relevant? Then in the future best
> leave them out (or make things easier to follow), they make the bug
> report confusing and sou
On 8/6/24 08:09, Vasily Khoruzhick wrote:
If the card doesn't have display hardware, hpd_work and hpd_lock are
left uninitialized which causes BUG when attempting to schedule hpd_work
on runtime PM resume.
Fix it by adding headless flag to DRM and skip any hpd if it's set.
Fixes: ae1aadb1eb8d
On 6/7/2024 7:45 PM, Abhinav Kumar wrote:
On 6/7/2024 5:57 PM, Dmitry Baryshkov wrote:
On Sat, 8 Jun 2024 at 02:55, Abhinav Kumar
wrote:
On 6/7/2024 3:26 PM, Dmitry Baryshkov wrote:
On Sat, 8 Jun 2024 at 00:39, Abhinav Kumar
wrote:
On 6/7/2024 2:10 PM, Dmitry Baryshkov wrote:
On
& quirks->ignore_min_input_signal) {
+ DRM_INFO("amdgpu_acpi quirk: min_input_signal=0\n");
+ atif->backlight_caps.min_input_signal = 0;
+ }
} else {
atif->backlight_caps.caps_valid = false;
}
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a
Best regards,
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Virtual wide planes give high amount of flexibility, but it is not
always enough:
In parallel multirect case only the half of the usual width is supported
for tiled formats. Thus the whole width of two tiled multirect
rectangles can not be greater
u_atcs *atcs = &amdgpu_acpi_priv.atcs;
> > struct pci_dev *pdev = NULL;
> > @@ -1429,6 +1460,10 @@ void amdgpu_acpi_detect(void)
> > ret);
> > atif->backlight_caps.caps_valid = false;
> > }
> > + if (quirks && quirks->ignore_min_input_signal) {
> > + DRM_INFO("amdgpu_acpi quirk: min_input_signal=0\n");
> > + atif->backlight_caps.min_input_signal = 0;
> > + }
> > } else {
> > atif->backlight_caps.caps_valid = false;
> > }
> >
> > ---
> > base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
> > change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a
> >
> > Best regards,
>
s.min_input_signal = 0;
+ }
} else {
atif->backlight_caps.caps_valid = false;
}
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a
Best regards,
DRM_INFO("amdgpu_acpi quirk: min_input_signal=0\n");
+ atif->backlight_caps.min_input_signal = 0;
+ }
} else {
atif->backlight_caps.caps_valid = false;
}
---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a
Best regards,
--
Thomas Weißschuh
On 6/10/24 16:41, Mina Almasry wrote:
On Mon, Jun 10, 2024 at 5:38 AM Christian König
wrote:
Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
On 6/10/24 01:37, David Wei wrote:
On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it
On 6/10/24 16:16, David Ahern wrote:
On 6/10/24 6:16 AM, Jason Gunthorpe wrote:
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
On 6/10/24 01:37, David Wei wrote:
On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it seems to compose poorly if you can only use the io_uring
lifec
On Tue, Jun 4, 2024 at 9:46 AM Jani Nikula wrote:
[Maybe slightly off-topic, ranty]
> Why do we think it's a good idea to increase and normalize the use of
> double-underscore function names across the kernel, like
> __match_string() in this case? It should mean "reserved for the
> implementatio
Device managed panel bridge wrappers are created by calling to
drm_panel_bridge_add_typed() and registering a release handler for
clean-up when the device gets unbound.
Since the memory for this bridge is also managed and linked to the panel
device, the release function should not try to free that
komeda_pipeline_get_state() may return an error-valued pointer, thus
check the pointer for negative or null value before dereferencing.
Signed-off-by: Amjad Ouled-Ameur
---
drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
On Mon, Jun 10, 2024 at 01:12:00PM +0200, Maxime Ripard wrote:
> It looks like the documentation for the HDMI-related fields recently
> added to both the drm_connector and drm_connector_state structures
> trigger some warnings because of their use of anonymous structures:
>
> $ scripts/kernel-do
On Mon, Jun 10, 2024 at 02:07:06PM +0200, Maxime Ripard wrote:
> Hi,
>
> +Hans
>
> On Mon, Jun 10, 2024 at 02:46:03PM GMT, Dmitry Baryshkov wrote:
> > On Mon, 10 Jun 2024 at 11:04, Maxime Ripard wrote:
> > >
> > > Hi,
> > >
> > > On Fri, Jun 07, 2024 at 04:22:59PM GMT, Dmitry Baryshkov wrote:
>
On Mon, Jun 10, 2024 at 06:02:41PM +0530, Aradhya Bhatia wrote:
> Hi Dmitry,
>
> Thank you for reviewing the patches.
>
> On 31/05/24 04:51, Dmitry Baryshkov wrote:
> > On Thu, May 30, 2024 at 03:06:19PM +0530, Aradhya Bhatia wrote:
> >> Change the existing (and deprecated) bridge hooks, to the b
On Thu, Jun 06, 2024 at 02:02:13PM +1200, Barry Song wrote:
> From: Barry Song
>
> dma_heap_allocation_data defines the UAPI as follows:
>
> struct dma_heap_allocation_data {
> __u64 len;
> __u32 fd;
> __u32 fd_flags;
> __u64 heap_flags;
> };
>
> But dma heaps
On Sun, Jun 09, 2024 at 03:19:55PM +1200, Ryan Walklin wrote:
> On Sat, 8 Jun 2024, at 2:23 AM, Conor Dooley wrote:
> >> + - const: allwinner,sun50i-h616-de33-clk
> >
> > I think this is not right, as a corresponding driver change is missing.
> > Either you're missing a clock driver patch or
On Mon, Jun 10, 2024 at 03:26:53PM +0200, Pierre-Eric Pelloux-Prayer wrote:
> v3: https://lists.freedesktop.org/archives/dri-devel/2024-June/456792.html
>
> Changes since v3:
> * trace device name instead of drm_device primary index
> * no pointer deref in the TP_printk anymore. Instead the fence
On Mon, Jun 10, 2024 at 02:38:18PM +0200, Christian König wrote:
> Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
> > On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
> > > On 6/10/24 01:37, David Wei wrote:
> > > > On 2024-06-07 17:52, Jason Gunthorpe wrote:
> > > > > IMHO it seems t
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/drm-connector-hdmi-Fix-kerneldoc-warnings/20240610-191427
base: git://anongit.freedesktop.o
On Mon, Jun 10, 2024 at 5:38 AM Christian König
wrote:
>
> Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
> > On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
> >> On 6/10/24 01:37, David Wei wrote:
> >>> On 2024-06-07 17:52, Jason Gunthorpe wrote:
> IMHO it seems to compose poo
submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/drm-connector-hdmi-Fix-kerneldoc-warnings/20240610-191427
base: git://anongit.freedesktop.o
On 6/10/24 6:16 AM, Jason Gunthorpe wrote:
> On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
>> On 6/10/24 01:37, David Wei wrote:
>>> On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it seems to compose poorly if you can only use the io_uring
lifecycle model with io_uring
Hi,
On Sat, Jun 8, 2024 at 3:57 AM Tejas Vipin wrote:
>
> Use functions introduced in 966e397e4f603 ("drm/mipi-dsi: Introduce
> mipi_dsi_*_write_seq_multi()") and f79d6d28d8fe
> ("drm/mipi-dsi: wrap more functions for streamline handling") for the
> sony tulip truly nt35521 panel.
Running "scrip
https://bugzilla.kernel.org/show_bug.cgi?id=218900
--- Comment #16 from Vasant Hegde (vasant.he...@amd.com) ---
(In reply to Hanabishi from comment #15)
> (In reply to Vasant Hegde from comment #5)
> > Created attachment 306364 [details]
> > Check Enhanced PPR support before enabling PPR
>
> I ap
On Tue, 4 Jun 2024 10:44:05 +0800, kuro wrote:
> From: Kuro Chung
>
> The spec of timing between IVDD/OVDD and SYSRTEN is 10ms, but SYSRSTN RC
> circuit need at least 25ms for rising time, update for match spec
>
>
Applied, thanks!
[1/1] drm/bridge: it6505: update usleep_range for RC circuit
On Sat, 1 Jun 2024 09:41:01 -0500, Adam Ford wrote:
> The P divider should be set based on the min and max values of
> the fin pll which may vary between different platforms.
> These ranges are defined per platform, but hard-coded values
> were used instead which resulted in a smaller range availab
Am 04.06.24 um 20:28 schrieb Deucher, Alexander:
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Kuehling, Felix
Sent: Tuesday, June 4, 2024 2:25 PM
To: Armin Wolf ; Deucher, Alexander
; Koenig, Christian
; Pan, Xinhui ;
gre...@linuxfoundation.org; sa
On Fri, 31 May 2024 22:33:12 +0200, Marek Vasut wrote:
> Make sure the connector is fully initialized before signalling any
> HPD events via drm_kms_helper_hotplug_event(), otherwise this may
> lead to NULL pointer dereference.
>
>
Applied, thanks!
[1/1] drm/bridge: tc358767: Check if fully ini
On Fri, 31 May 2024 22:32:01 +0200, Marek Vasut wrote:
> Fix comment copy-paste error in tc_edp_mode_valid(), this function
> is validating DP/eDP clock, not DPI clock frequency. Update the
> comment to match. No functional change.
>
>
Applied, thanks!
[1/1] drm/bridge: tc358767: Fix comment in
The various models have common code for the VGA output's encoder and
connector. Move everything into a single shared source file. Remove some
obsolete initializer macros. No functional changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/Makefile | 3 +-
drivers/gpu/dr
The BMC output can be viewed via the BMC's web interface or a
similar client. Represent it as virtual encoder and connector.
It's attached to the same CRTC as the VGA connector.
The connector's status depends on the physical connector's status.
The BMC is only connected if the physical connector i
Set .detect_ctx() in struct drm_connector_helper_funcs to the
common helper drm_connector_helper_detect_from_ddc() and enable
polling for the connector. Mgag200 will now test for the monitor's
presence by probing the DDC in regular intervals.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/
Detect the connector status by polling the DDC. Update the status at
runtime. Add a dedicated BMC output to still display to the BMC while
the VGA connector is not attached.
This patchset fixes a long-standing problem where attaching the VGA
display a runtime resulted in incorrect display modes.
tree: git://anongit.freedesktop.org/drm/drm-misc topic/rust-drm
head: 508348922df19178b613531fb6cc7beb624642ae
commit: 28ea76b321b25ee422d9c9bd08f1bf605a9ae422 [9/20] rust: add device::Data
config: x86_64-rhel-8.3-rust
(https://download.01.org/0day-ci/archive/20240610/202406102138.eekfigxb
Trace the fence dependencies similarly to how we print fences:
... , dependencies:{(context:606, seqno:38006)}
This allows tools to analyze the dependencies between the jobs (previously
it was only possible for fences traced by drm_sched_job_wait_dep).
Since drm_sched_job and drm_run_job use th
Print identifiers instead of pointers:
* "fence=%p" is replaced by "fence=(context:%llu, seqno:%lld)" to have a
coherent way to print the fence. A possible follow up change would be
to use the same format in traces/../dma-fence.h.
* "entity=%p" is removed because the fence's context is already an
i
Until the switch from kthread to workqueue, a userspace application could
determine the source device from the pid of the thread sending the event.
With workqueues this is not possible anymore, so the event needs to contain
the dev_name() to identify the device.
Signed-off-by: Pierre-Eric Pelloux
v3: https://lists.freedesktop.org/archives/dri-devel/2024-June/456792.html
Changes since v3:
* trace device name instead of drm_device primary index
* no pointer deref in the TP_printk anymore. Instead the fence context/seqno
are saved in TP_fast_assign
Pierre-Eric Pelloux-Prayer (3):
drm/sched
On Sat, Jun 08, 2024 at 08:28:06AM +0900, FUJITA Tomonori wrote:
> On Fri, 7 Jun 2024 19:55:49 +0200
> Danilo Krummrich wrote:
>
> > On Fri, Jun 07, 2024 at 05:41:11PM +0200, Greg KH wrote:
> >> On Fri, Jun 07, 2024 at 03:33:39PM +0200, Danilo Krummrich wrote:
> >> > On Fri, Jun 07, 2024 at 02:36
Hi Andi,
On 10/06/2024 13:10, Andi Shyti wrote:
Hi Tvrtko,
On Mon, Jun 10, 2024 at 12:42:31PM +0100, Tvrtko Ursulin wrote:
On 03/06/2024 17:20, Niemiec, Krzysztof wrote:
The test is trying to push the heartbeat frequency to the limit, which
might sometimes fail. Such a failure does not prov
On Fri, 31 May 2024 22:37:44 +0200, Sam Ravnborg wrote:
> I had a few bridge related patches in an old branch.
>
> They were last posted here almost one year ago:
> https://lore.kernel.org/dri-devel/20220717174454.46616-1-...@ravnborg.org/
>
> The following two patches gets rid of drm_bridge_chai
On Mon, Jun 10, 2024 at 12:46:11PM GMT, Maxime Ripard wrote:
> On Sat, 24 Feb 2024 16:05:57 +0100, Ondřej Jirman wrote:
> > From: Ondrej Jirman
> >
> > This series refactors blender setup from individual planes to a common
> > place where it can be performed at once and is easier to reason about.
Am Freitag, 3. Mai 2024, 17:11:15 CEST schrieb Lucas Stach:
> Currently the AUX channel support in the Analogix DP driver is severely
> limited as the AUX block of the bridge is only initialized when the video
> link is to be enabled. This is okay for the purposes of link training,
> but does not a
Am Freitag, 3. Mai 2024, 17:11:17 CEST schrieb Lucas Stach:
> Hook up the runtime PM suspend/resume paths to make the rockchip
> glue behave more like the exynos one. The same suspend/resume
> functions are used for system sleep via the runtime PM force
> suspend/resume.
>
> Signed-off-by: Lucas S
Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 2 new issues were detected and 0 were fixed.
In total, 18 issues are still open and 31 have been
Am 10.06.24 um 14:16 schrieb Jason Gunthorpe:
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
On 6/10/24 01:37, David Wei wrote:
On 2024-06-07 17:52, Jason Gunthorpe wrote:
IMHO it seems to compose poorly if you can only use the io_uring
lifecycle model with io_uring registered
Hi Dmitry,
Thank you for reviewing the patches.
On 31/05/24 04:51, Dmitry Baryshkov wrote:
> On Thu, May 30, 2024 at 03:06:19PM +0530, Aradhya Bhatia wrote:
>> Change the existing (and deprecated) bridge hooks, to the bridge
>> atomic APIs.
>>
>> Add drm helpers for duplicate_state, destroy_state
On Mon, Jun 10, 2024 at 02:07:01AM +0100, Pavel Begunkov wrote:
> On 6/10/24 01:37, David Wei wrote:
> > On 2024-06-07 17:52, Jason Gunthorpe wrote:
> > > IMHO it seems to compose poorly if you can only use the io_uring
> > > lifecycle model with io_uring registered memory, and not with DMABUF
> >
On 07/06/2024 11:16, Javier Martinez Canillas wrote:
Jocelyn Falempe writes:
Add a kmsg option, which will display the last lines of kmsg,
and should be similar to fbcon.
Add a drm.panic_screen module parameter, so you can choose between
the different panic screens available.
two options cu
Hi Tvrtko,
On Mon, Jun 10, 2024 at 12:42:31PM +0100, Tvrtko Ursulin wrote:
> On 03/06/2024 17:20, Niemiec, Krzysztof wrote:
> > The test is trying to push the heartbeat frequency to the limit, which
> > might sometimes fail. Such a failure does not provide valuable
> > information, because it does
Hi,
+Hans
On Mon, Jun 10, 2024 at 02:46:03PM GMT, Dmitry Baryshkov wrote:
> On Mon, 10 Jun 2024 at 11:04, Maxime Ripard wrote:
> >
> > Hi,
> >
> > On Fri, Jun 07, 2024 at 04:22:59PM GMT, Dmitry Baryshkov wrote:
> > > Turn drm_bridge_connector to using drmm_kzalloc() and
> > > drmm_connector_init
Am 06.06.24 um 14:35 schrieb Jani Nikula:
Debug printing at DisplayID validation leads to lots of log spamming as
it's called at DisplayID iterators during EDID parsing. Remove it, and
replace with a less noisy message at connector EDID update.
Signed-off-by: Jani Nikula
Acked-by: Thomas Z
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> Timeouts on the AUX bus are to be expected in certain normal operating
> conditions. There is no need to raise an error log or re-initialize the
> whole AUX state machine. Simply acknowledge the AUX_ERR interrupt and
> let upper layers know abo
On Fri, May 3, 2024 at 5:13 PM Lucas Stach wrote:
>
> All AUX error responses raise the AUX_ERR interrupt, so there is no
> need to read the AUX status register in normal operation. Only read
> the status when an error occured and we can expect a different status
> than OK.
>
> Signed-off-by: Luca
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> Move the wait loop into its own function, so it doesn't need to be
> replicated in multiple locations. Also move the PLL lock checks between
> setting the link bandwidth, which may cause the PLL to unlock, and the
> MACRO_RST, which needs the P
On Fri, May 3, 2024 at 5:12 PM Lucas Stach wrote:
>
> The PLL will be reconfigured later, which may cause it to go out of lock
> anyways, so there is no point in waiting for the PLL to lock here. Instead
> we can continue execution of the link setup, which will properly set the
> PLL parameters an
On Mon, 10 Jun 2024 at 11:04, Maxime Ripard wrote:
>
> Hi,
>
> On Fri, Jun 07, 2024 at 04:22:59PM GMT, Dmitry Baryshkov wrote:
> > Turn drm_bridge_connector to using drmm_kzalloc() and
> > drmm_connector_init() and drop the custom destroy function. The
> > drm_connector_unregister() and fwnode_han
On Tue, May 7, 2024 at 3:07 PM Robert Foss wrote:
>
> On Fri, May 3, 2024 at 5:13 PM Lucas Stach wrote:
> >
> > Setting the link bandwidth may change the PLL parameters, which will cause
> > the PLL to go out of lock, so make sure to apply the MACRO_RST, which
> > according to the comment is requ
On 03/06/2024 17:20, Niemiec, Krzysztof wrote:
The test is trying to push the heartbeat frequency to the limit, which
might sometimes fail. Such a failure does not provide valuable
information, because it does not indicate that there is something
necessarily wrong with either the driver or the
On Mon, 10 Jun 2024 13:50:26 +0300, Dan Carpenter wrote:
> Smatch complains correctly that the NULL checking isn't consistent:
>
> drivers/gpu/drm/bridge/ite-it6505.c:2583 it6505_poweron()
> error: we previously assumed 'pdata->pwr18' could be null
> (see line 2569)
>
> These the ->pw
On Mon, Jun 10, 2024 at 11:27:39AM GMT, Adam Miotk wrote:
> Device managed panel bridge wrappers are created by calling to
> drm_panel_bridge_add_typed() and registering a release handler for
> clean-up when the device gets unbound.
>
> Since the memory for this bridge is also managed and linked t
On Mon, Jun 10, 2024 at 11:20:56AM GMT, Amjad Ouled-Ameur wrote:
> komeda_pipeline_get_state() may return an error-valued pointer, thus
> check the pointer for negative or null value before dereferencing.
>
> Signed-off-by: Amjad Ouled-Ameur
I've added a Fixes tag and applied to drm-misc-fixes,
Hi,
On Mon, Jun 10, 2024 at 01:12:00PM GMT, Maxime Ripard wrote:
> It looks like the documentation for the HDMI-related fields recently
> added to both the drm_connector and drm_connector_state structures
> trigger some warnings because of their use of anonymous structures:
>
> $ scripts/kernel
It looks like the documentation for the HDMI-related fields recently
added to both the drm_connector and drm_connector_state structures
trigger some warnings because of their use of anonymous structures:
$ scripts/kernel-doc -none include/drm/drm_connector.h
include/drm/drm_connector.h:1138: w
Smatch complains correctly that the NULL checking isn't consistent:
drivers/gpu/drm/bridge/ite-it6505.c:2583 it6505_poweron()
error: we previously assumed 'pdata->pwr18' could be null
(see line 2569)
These the ->pwr18 pointer is allocated during probe using the
devm_regulator_get() fu
On Sat, 24 Feb 2024 16:05:57 +0100, Ondřej Jirman wrote:
> From: Ondrej Jirman
>
> This series refactors blender setup from individual planes to a common
> place where it can be performed at once and is easier to reason about.
>
> In the process this fixes a few bugs that allowed blender pipes t
On Sun, 09 Jun 2024 11:42:53 -0700, Jeff Johnson wrote:
> On x86, make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/gud/gud.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/drm_panel_orientation_quirks.o
> WARNING:
On Sun, 09 Jun 2024 10:06:17 -0700, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/bridge/lontium-lt9611.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/bridge/lontium-lt9611uxc.o
> WAR
On Sun, 09 Jun 2024 10:20:27 -0700, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/tiny/bochs.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/tiny/cirrus.o
> WARNING: modpost: missing MODU
On Sun, 09 Jun 2024 09:53:21 -0700, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/panel/panel-abt-y030xx067a.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/panel/panel-auo-a030jtn01.o
On Thu, 06 Jun 2024 21:42:46 -0700, Jeff Johnson wrote:
> make allmodconfig && make W=1 C=1 reports:
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/tests/drm_kunit_helpers.o
> WARNING: modpost: missing MODULE_DESCRIPTION() in
> drivers/gpu/drm/tests/drm_buddy_test.o
> WARNI
On Mon, 2024-06-10 at 11:31 +0200, Philipp Stanner wrote:
> 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.
>
> This will later permit simplif
Hi Tobias,
On 5/31/24 9:04 PM, Tobias Jakobi wrote:
> On 3/10/24 23:04, tjak...@math.uni-bielefeld.de wrote:
>
>> From: Tobias Jakobi
>>
>> Similar to the other Aya Neo devices this one features
>> again a portrait screen, here with a native resolution
>> of 1600x2560.
>>
>> Signed-off-by: Tobia
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 region-request
pcim_iomap_table() should not be used anymore because it contributed to the
PCI devres API being designed contrary to devres's design goals.
pcim_iomap_regions_request_all() is a surplus, complicated function that
can easily be replaced by using a pcim_* request function in combination
with a pcim
The PCI devres implementation has a separate boolean to track whether a
device is enabled. However, that can easily be tracked through the
function pci_is_enabled() which is agnostic.
Using it allows for simplifying the PCI devres implementation.
Replace the separate 'enabled' status bit from str
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 PCI devres API in
which some, but not all, fu
The only managed mapping function currently is pcim_iomap() which
doesn't allow for mapping an area starting at a certain offset, which
many drivers want.
Add pcim_iomap_range() as an exported function.
Signed-off-by: Philipp Stanner
---
drivers/pci/devres.c | 44 +++
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 PCI devres implementation.
Replace pcim_release() with pcim_disable_devi
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
---
drivers/pci/
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.
This will later permit simplifying pcim_enable_device().
Move the 'pinned' boolean bit to struct
The current derves implementation uses manual shift operations to check
whether a bit in a mask is set. The code can be made more readable by
writing a small helper function for that.
Implement mask_contains_bar() and use it where applicable.
Link: https://lore.kernel.org/r/20240605081605.18769-3
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 a bug (in 8558de401b5f) by confusing users, who
came to believe that all pci functions, such as pci_iomap_range(), suddenly
are man
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 pcim_request_region_exclusive() as a PCI-internal helper. Have
t
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 functions have bit masks as parameters to specify which BARs shall
get mapped. Most users, however, only use those to map 1-3 BARs.
A complete s
The pcim_iomap_devres.table administrated by pcim_iomap_table() has its
entries set and unset at several places throughout devres.c using manual
iterations which are effectively code duplications.
Add pcim_add_mapping_to_legacy_table() and
pcim_remove_mapping_from_legacy_table() helper functions a
This v8 is based on [1]. It contains the already applied patches in
unchanged form; just for readability and consistency.
Thx for taking the first set of patches! This series provides the
enabled_cnt rework and some other minor fixes. See below.
[1] https://git.kernel.org/pub/scm/linux/kernel/git
Hi Andi,
On 6/7/2024 4:51 PM, Andi Shyti wrote:
The forcewake count and domains listing is multi process critical
and the uncore provides a spinlock for such cases.
Lock the forcewake evaluation section in the fw_domains_show()
debugfs interface.
Signed-off-by: Andi Shyti
Needs a Fixes tag,
Hi, Jani Nikula,
Thanks for your contribution and sorry for being late. Below are my comments.
2024년 5월 14일 (화) 오후 9:57, Jani Nikula 님이 작성:
>
> Prefer the struct drm_edid based functions for reading the EDID and
> updating the connector.
>
> The functional change is that the CEC physical address
The iommu_domain_alloc() interface is no longer used in the tree anymore.
Remove it to avoid dead code.
There is increasing demand for supporting multiple IOMMU drivers, and this
is the last bus-based thing standing in the way of that.
Signed-off-by: Lu Baolu
---
include/linux/iommu.h | 6
The iommu_present() interface is no longer used in the tree anymore.
Remove it to avoid dead code.
Signed-off-by: Lu Baolu
---
include/linux/iommu.h | 6 --
drivers/iommu/iommu.c | 25 -
2 files changed, 31 deletions(-)
diff --git a/include/linux/iommu.h b/include/l
Commit <17de3f5fdd35> ("iommu: Retire bus ops") removes iommu ops from
the bus structure. The iommu subsystem no longer relies on bus for
operations. So iommu_domain_alloc() interface is no longer relevant.
Normally, iommu_paging_domain_alloc() could be a replacement for
iommu_domain_alloc() if th
1 - 100 of 134 matches
Mail list logo
