In order to use dynamic-debug's jump-label optimization in drm-debug,
its clarifying to refine drm_debug_enabled into 3 uses:
1. drm_debug_enabled - legacy, public
2. __drm_debug_enabled - optimized for dyndbg jump-label enablement.
3. _drm_debug_enabled - pr_debug instrumented, observable
1.
With DECLARE_DYNDBG_CLASSMAP modules can declare up to 31 classnames.
By doing so, they authorize dyndbg to manipulate class'd prdbgs (ie:
__pr_debug_cls, and soon drm_*dbg)
:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
The macro declares and initializes a static struct ddebug_cla
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is gene
For selftest purposes, add __pr_debug_cls(class, fmt, ...)
I didn't think we'd need to define this, since DRM effectively has it
already in drm_dbg, drm_devdbg. But test_dynamic_debug needs it in
order to demonstrate all the moving parts.
Note the __ prefix; its not intended for general use, at
For CONFIG_DRM_USE_DYNAMIC_DEBUG=y, wrap __drm_dbg() & __drm_dev_dbg()
in one of dyndbg's Factory macros: _dynamic_func_call_no_desc().
This adds the callsite descriptor into the code, and an entry for each
into /proc/dynamic_debug/control.
#> echo class DRM_UT_ATOMIC +p > /proc/dynamic_debug/c
clone the nvkm_printk,_,__ macro ladder into nvkm_drmdbg,_,__.
And alter the debug, trace, spam macros to use the renamed ladder.
This *sets-up* (not done yet) to remove the _subdev->debug >= (l)
condition, once the bitmap-param is wired up correctly, and figured
into dyndbg's jump-label enablemen
These 2 macros used drm_debug_enabled() on DRM_UT_{DRIVER,ATOMIC}
respectively, replace those with drm_dbg_##cat invocations.
this results in new class'd prdbg callsites:
:#> grep nouveau /proc/dynamic_debug/control | grep class | wc
1161130 15584
:#> grep nouveau /proc/dynamic_debug/co
drm_print defines all of these:
drm_dbg_{core,kms,prime,atomic,vbl,lease,_dp,_drmres}
but not drm_dbg_driver itself, since it was the original drm_dbg.
To improve namespace symmetry, change the drm_dbg defn to
drm_dbg_driver, and redef grandfathered name to symmetric one.
This will help with
Add an explanation of the new "class CLASS_NAME" syntax and meaning,
noting that the module determines if CLASS_NAME applies to it.
Signed-off-by: Jim Cromie
---
Documentation/admin-guide/dynamic-debug-howto.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/admin
These 2 macros formerly used dev_info, and they still check
subdev->debug to gate the printing. So dyndbg control is redundant
ATM (and possibly confusing, since its off by default).
prdbg count is up from 3, or from 65 (with VMM_DEBUG here)
[7.765379] dyndbg: 516 debug prints in module nouv
Use DECLARE_DYNDBG_CLASSMAP across DRM:
- in .c files, since macro defines/initializes a record
- in drivers, $mod_{drv,drm,param}.c
ie where param setup is done, since a classmap is param related
- in drm/drm_print.c
since existing __drm_debug param is defined there,
and we ifdef it
upgrade the callchain to drm_dbg() and drm_dev_dbg(); add a struct
_ddebug ptr parameter to them, and supply that additional param by
replacing the '_no_desc' flavor of dyndbg Factory macro currently used
with the flavor that supplies the descriptor.
NOTES:
The descriptor gives these fns access t
Add module-to-class validation:
#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control
If a query has "class FOO", then ddebug_find_valid_class(), called
from ddebug_change(), requires that FOO is known to module X,
otherwize the query is skipped entirely for X. This protects each
module's
change drm_dev_dbg & drm_dbg to macros, which forward to the renamed
functions (with __ prefix added).
Those functions sit below the categorized layer of macros implementing
the DRM debug.category API, and implement most of it. These are good
places to insert dynamic-debug jump-label mechanics, w
Demonstrate use of DECLARE_DYNDBG_CLASSMAP macro, and expose them as
sysfs-nodes for testing.
For each of the 4 class-map-types:
- declare a class-map of that type,
- declare the enum corresponding to those class-names
- share _base across 0..30 range
- add a __pr_debug_cls() call for eac
Add __dyndbg_classes section, using __dyndbg as a model. Use it:
vmlinux.lds.h:
KEEP the new section, which also silences orphan section warning on
loadable modules. Add (__start_/__stop_)__dyndbg_classes linker
symbols for the c externs (below).
kernel/module/main.c:
- fill new fields in find_
DRM issues ~10 exclusive categories of debug messages; to represent
this directly in dyndbg, add a new field: struct _ddebug.class_id:5.
This gives us 32 classes, which is a practical usability limit
with a bitmap interface:
#> echo 0x012345678 > /sys/module/drm/parameters/debug
All existing c
lkp robot told me:
>> drivers/gpu/drm/drm_ioc32.c:989:2:
error: call to undeclared function '_dynamic_func_call_cls';
ISO C99 and later do not support implicit function declarations
[-Wimplicit-function-declaration]
DRM_DEBUG("comm=\"%s\", pid=%d, dev=0x%lx, auth=%d, %s\n",
Si
Add ddebug_attach_module_classes(), call it from ddebug_add_module().
It scans the classes/section its given, finds records where the
module-name matches the module being added, and adds them to the
module's maps list. No locking here, since the record
isn't yet linked into the ddebug_tables list.
this new struct gathers the linker provided vectors/sections:
descs - the vector of descriptors in __dyndbg section.
num_descs - length of the data/section
Use it as follows:
In lib/dynamic_debug.c:
Alter ddebug_add_module() params-list, replacing descriptor-table and
its length with a sing
enum drm_debug_category has 10 categories, but is initialized with
bitmasks which require 10 bits of underlying storage. By using
natural enumeration, and moving the BIT(cat) into drm_debug_enabled(),
the enum fits in 4 bits, allowing the category to be represented
directly in pr_debug callsites,
Add kernel_param_ops and callbacks to use a class-map to validate and
apply input to a sysfs-node, which allows users to control classes
defined in that class-map. This supports uses like:
echo 0x3 > /sys/module/drm/parameters/debug
IE add these:
- int param_set_dyndbg_classes()
- int param
Provide a simple module to allow testing DYNAMIC_DEBUG behavior. It
calls do_prints() from module-init, and with a sysfs-node.
dmesg -C
dmesg -w &
modprobe test_dynamic_debug dyndbg=+p
echo 1 > /sys/module/dynamic_debug/parameters/verbose
cat /sys/module/test_dynamic_debug/parameters/d
Rework/modernize docs:
- use /proc/dynamic_debug/control in examples
its *always* there (when dyndbg is config'd), even when is not.
drop talk, its a distraction here.
- alias ddcmd='echo $* > /proc/dynamic_debug/control
focus on args: declutter, hide boilerplate, make pwd independen
rework var-names for clarity, regularity
rename variables
- n to mod_sites - it counts sites-per-module
- entries to i - display only
- iter_start to iter_mod_start - marks start of each module's subrange
- modct to mod_ct - stylistic
new iterator var:
- site - cursor parallel to iter
dyndbg's control-parser: ddebug_parse_query(), requires that search
terms: module, func, file, lineno, are used only once in a query; a
thing cannot be named both foo and bar.
The cited commit added an overriding module modname, taken from the
module loader, which is authoritative. So it set quer
`cat control` currently does octal escape, so '\n' becomes "\012".
Change this to display as "\n" instead, which reads much cleaner.
:#> head -n7 /proc/dynamic_debug/control
# filename:lineno [module]function flags format
init/main.c:1179 [main]initcall_blacklist =_ "blacklisting initcall
This exported fn is unused, and will not be needed. Lets dump it.
The export was added to let drm control pr_debugs, as part of using
them to avoid drm_debug_enabled overheads. But its better to just
implement the drm.debug bitmap interface, then its available for
everyone.
Fixes: a2d375eda771 (
Walk the module's vector of callsites backwards; ie N..0. This
"corrects" the backwards appearance of a module's prdbg vector when
walked 0..N. I think this is due to linker mechanics, which I'm
inclined to treat as immutable, and the order is fixable in display.
No functional changes.
Combined
For CONFIG_DYNAMIC_DEBUG=N, the ddebug_dyndbg_module_param_cb()
stub-fn is too permissive:
bash-5.1# modprobe drm JUNKdyndbg
bash-5.1# modprobe drm dyndbgJUNK
[ 42.933220] dyndbg param is supported only in CONFIG_DYNAMIC_DEBUG builds
[ 42.937484] ACPI: bus type drm_connector registered
This c
/proc/dynamic_debug/control walks the prdbg catalog in "reverse",
fix this by adding new ddebug_tables to tail of list.
This puts init/main.c entries 1st, which looks more than coincidental.
no functional changes.
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
lib/dynamic_debug.c | 2 +-
In https://lore.kernel.org/lkml/20211209150910.ga23...@axis.com/
Vincent's patch commented on, and worked around, a bug toggling
static_branch's, when a 2nd PRINTK-ish flag was added. The bug
results in a premature static_branch_disable when the 1st of 2 flags
was disabled.
The cited commit comp
print "old => new" flag values to the info("change") message.
no functional change.
Signed-off-by: Jim Cromie
Acked-by: Jason Baron
---
lib/dynamic_debug.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a56c1286ff
Hi Jason, Greg, DRM-folk,
heres V5. Diffs vs V4:
1st 9 have Jason's Ack
10 is new: simple var cleanup
11 new struct, to contain future addins. touches kernel/module/
dyndbg-param callbacks moved to last (of dyndbg patches)
they're where the uncertainty is,
and the bulk of the API add
On Fri, Jul 22, 2022 at 05:32:12PM -0400, Jim Shargo wrote:
> This change adds the basic scaffolding for ConfigFS, including setting
> up the default directories. It does not allow for the registration of
> configfs-backed devices, which is complex and provided in a follow-up
> commit.
>
> This CL
lgtm!
Reviewed-by: Lyude Paul
On Fri, 2022-08-05 at 17:13 -0400, Hamza Mahfooz wrote:
> Currently, there is no way to identify if DSC pass-through can be
> enabled and what aux DSC pass-through requests ought to be sent to. So,
> add a variable to struct drm_dp_mst_port that keeps track of the
>
Currently, we only attempt to setup DSC at the virtual DPCD port,
however many modern displays come with DSC support and MST hubs can now
support DSC pass-through. So, to more optimally make use of the
available bandwidth, use DSC pass-through when possible by adding DSC
pass-through enablement sup
Add a mode validation routine for DSC pass-through. Both the link from
source to hub, and the link from hub to monitor are checked, according
to the current link training result and full pbn returned by enum path
resource sideband message.
Pick up the minimum value as the bandwidth bottleneck for
Currently, there is no way to identify if DSC pass-through can be
enabled and what aux DSC pass-through requests ought to be sent to. So,
add a variable to struct drm_dp_mst_port that keeps track of the
aforementioned information.
Signed-off-by: Hamza Mahfooz
---
v2: define DP_DSC_PASSTHROUGH_IS_
On Fri, Aug 5, 2022 at 7:56 AM Adam Ford wrote:
>
> On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote:
> >
> > On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote:
> > >
> > > Hi Adam and all,
> > >
> > > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> > > >
> > > > On Thu, Aug 4, 2022 at
Hi Dave and Daniel,
Please pick this one instead of drm-intel-next-fixes-2022-08-04.
Mauro has pointed out that the commit "drm/i915/gt: Batch TLB invalidations"
was introducing a worst regression in comparison to its intent.
The work is in progress to fix on our -next branches, but we shouldn't
On Fri, Aug 05, 2022 at 05:25:43PM +0200, Mauro Carvalho Chehab wrote:
> On Fri, 5 Aug 2022 10:39:44 -0400
> Rodrigo Vivi wrote:
>
> > On Fri, Aug 05, 2022 at 10:46:57AM +0200, Mauro Carvalho Chehab wrote:
> > > Hi Rodrigo,
> > >
> > > On Thu, 4 Aug 2022 13:33:06 -0400
> > > Rodrigo Vivi wrote:
On Fri, Jul 22, 2022 at 05:32:11PM -0400, Jim Shargo wrote:
> This change supports multiple CRTCs, encoders, connectors instead of one
> of each per card.
>
> Since ConfigFS-based devices will support multiple crtcs, it's useful to
> move all of the writeback/composition data from being a per-outp
On Fri, Aug 5, 2022 at 8:02 PM Nathan Chancellor wrote:
> On Fri, Aug 05, 2022 at 06:16:45PM +0200, Arnd Bergmann wrote:
> > On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland
> > wrote:
> > While splitting out sub-functions can help reduce the maximum stack
> > usage, it seems that in this case it m
On Fri, Jul 22, 2022 at 05:32:10PM -0400, Jim Shargo wrote:
> This is a small refactor to make ConfigFS support easier.
>
> We now store the vkms_device statically, and maintain a list of
> "cards", each representing a different virtual DRM driver.
>
> We also make it clear when a card is "defaul
From: Christophe JAILLET Sent: Sunday, July 31,
2022 1:02 PM
>
> hyperv_setup_vram() calls vmbus_allocate_mmio().
> This must be undone in the error handling path of the probe, as already
> done in the remove function.
>
> This patch depends on commit a0ab5abced55 ("drm/hyperv : Removing the
>
On Fri, Aug 05, 2022 at 06:27:08PM +, Sean Paul wrote:
> On Fri, Jul 22, 2022 at 05:32:10PM -0400, Jim Shargo wrote:
> > This is a small refactor to make ConfigFS support easier.
> >
> > We now store the vkms_device statically, and maintain a list of
> > "cards", each representing a different
On Fri, Jul 22, 2022 at 05:32:10PM -0400, Jim Shargo wrote:
> This is a small refactor to make ConfigFS support easier.
>
> We now store the vkms_device statically, and maintain a list of
> "cards", each representing a different virtual DRM driver.
>
> We also make it clear when a card is "defaul
On Fri, Aug 05, 2022 at 06:16:45PM +0200, Arnd Bergmann wrote:
> On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland wrote:
> > > I do notice that these files build with a non-configurable
> > > -Wframe-large-than value:
> > >
> > > $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile
> > >
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:00PM +0200, Thomas Zimmermann wrote:
> Change format-conversion helpers to use struct iosys_map for source
> and destination buffers. Update all users. Also prepare interface for
> multi-plane color formats.
>
> The format-conversion helpers mostly used to
Hi Thomas,
On Wed, Jul 27, 2022 at 01:33:12PM +0200, Thomas Zimmermann wrote:
> The format-convertion helpers handle several cases for different
> values of destination buffer and pitch. Move that code into the
> internal helper drm_fb_xfrm() and avoid quite a bit of duplucation.
This is very nic
On 8/4/22 14:41, Zheyu Ma wrote:
> In the function *_set_par(), the value of 'screen_size' is
> calculated by the user input. If the user provides the improper value,
> the value of 'screen_size' may larger than 'info->screen_size', which
> may cause a bug in the memset_io().
>
> Zheyu Ma (3):
>
On Fri, Aug 5, 2022 at 5:32 PM Harry Wentland wrote:
> > I do notice that these files build with a non-configurable
> > -Wframe-large-than value:
> >
> > $ rg frame_warn_flag drivers/gpu/drm/amd/display/dc/dml/Makefile
> > 54:frame_warn_flag := -Wframe-larger-than=2048
>
> Tbh, I was looking at th
From: Piotr Piórkowski
When initializing the i915, we want to be sure that the PCI
BARs have been properly initialized.
As part of this series, I have prepared two patches,
one that introduces BARs names to use in code instead of numbers,
and another that adds function to validate BARs before use
From: Piotr Piórkowski
For proper operation of i915 we need usable PCI GTTMMADDR BAR 0
(1 for GEN2). In most cases we also need usable PCI GFXMEM BAR 2.
Let's add functions to check if BARs are set, and that it have
a size greater than 0.
In case GTTMMADDR BAR, let's validate at the beginning of
From: Piotr Piórkowski
At the moment, when we refer to some PCI BAR we use the number of
this BAR in the code. The meaning of BARs between different platforms
may be different. Therefore, in order to organize the code,
let's start using defined names instead of numbers.
v2: Add lost header in cf
+Rob and devicetree list.
I don't know if this should be "linaro" or something more generic,
and also where previous discussions got to about DMA heaps in DT.
Cheers,
-Brian
On Fri, Aug 05, 2022 at 03:53:29PM +0200, Olivier Masse wrote:
> DMABUF Reserved memory definition for OP-TEE SDP feaure.
Hi Olivier,
Thanks, I think this is looking much better.
I'd like to know how others feel about landing this heap; there's been
push-back in the past about heaps in device-tree and discussions
around how "custom" heaps should be treated (though IMO this is quite
a generic one).
On Fri, Aug 05, 2
On Fri, Jul 22, 2022 at 05:32:09PM -0400, Jim Shargo wrote:
> This is a small refactor to make ConfigFS support easier.
>
> vkms_config is now a member of vkms_device and we now store a top-level
> reference to vkms_device.
>
> This should be a no-op refactor.
>
> Signed-off-by: Jim Shargo
> --
On 2022-08-04 16:43, Nathan Chancellor wrote:
> On Thu, Aug 04, 2022 at 09:24:41PM +0200, Arnd Bergmann wrote:
>> On Thu, Aug 4, 2022 at 8:52 PM Linus Torvalds
>> wrote:
>>>
>>> On Thu, Aug 4, 2022 at 11:37 AM Sudip Mukherjee (Codethink)
>>> wrote:cov_trace_cmp
git bisect points to 3
On Fri, 5 Aug 2022 10:39:44 -0400
Rodrigo Vivi wrote:
> On Fri, Aug 05, 2022 at 10:46:57AM +0200, Mauro Carvalho Chehab wrote:
> > Hi Rodrigo,
> >
> > On Thu, 4 Aug 2022 13:33:06 -0400
> > Rodrigo Vivi wrote:
> >
> > > Hi Dave and Daniel,
> > >
> > > Here goes drm-intel-next-fixes-2022-08-0
On Fri, Aug 05, 2022 at 10:46:57AM +0200, Mauro Carvalho Chehab wrote:
> Hi Rodrigo,
>
> On Thu, 4 Aug 2022 13:33:06 -0400
> Rodrigo Vivi wrote:
>
> > Hi Dave and Daniel,
> >
> > Here goes drm-intel-next-fixes-2022-08-04:
> >
> > - disable pci resize on 32-bit systems (Nirmoy)
> > - don't leak
Hi Brian,
Sorry for pushing all the patches again, but I've done some cleanup
regarding your comments.
secure-heap are now protected by default and no mapping could be done
for the CPU.
deferred-free is no more needed.
useless page pool code removed too.
Best regards,
Olivier
On mer., 2022-08-
Add DMABUF_HEAPS_SECURE in defconfig
Signed-off-by: Olivier Masse
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 11 +++
arch/arm64/configs/defconfig | 2 ++
2 files changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/ar
add Linaro secure heap bindings: linaro,secure-heap
use genalloc to allocate/free buffer from buffer pool.
buffer pool info is from dts.
use sg_table instore the allocated memory info, the length of sg_table is 1.
implement secure_heap_buf_ops to implement buffer share in difference device:
1. User
DMABUF Reserved memory definition for OP-TEE SDP feaure.
Signed-off-by: Olivier Masse
---
.../reserved-memory/linaro,secure-heap.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reserved-memory/linaro,secure-heap.yaml
diff
Purpose of these patches is to add a new dma-buf heap: linaro,secure-heap
Linaro OPTEE OS Secure Data Path feature is relying on a reserved memory
defined at Linux Kernel level and OPTEE OS level.
>From Linux Kernel side, heap management is using dma-buf heaps interface.
Olivier Masse (3):
dma-b
We only ever need to emit one ccs block copy command.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Ramalingam C
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 35 +++--
1 file changed, 3 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migra
Crucible + recent Mesa seems to sometimes hit:
GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER)
And it looks like we can also trigger this with gem_lmem_swapping, if we
modify the test to use slightly larger object sizes.
Looking closer it looks like we have the following issues in
migrate_copy(
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: Alice Chen
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
> LED current sour
On Fri, Aug 5, 2022 at 9:08 AM ChiaEn Wu wrote:
>
> From: ChiaEn Wu
>
> MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> driver, display bias voltage supply, one general purpose LDO, and the
> USB T
Suppose that I want to map a GPU buffer to the CPU and do image analysis on it.
I know all the usual cautions about this being a poor performance option, etc.
But suppose for the moment that the use-case requires it.
What's the right set of preconditions to conclude that the buffer is in vanilla
On Fri, Aug 5, 2022 at 5:55 AM Adam Ford wrote:
>
> On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote:
> >
> > Hi Adam and all,
> >
> > > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> > >
> > > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > > wrote:
> > > >
> > > > On Thu, 4 Aug 2
On 2022-08-05 14:56:30, Dmitry Baryshkov wrote:
> The commit 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master
> components") changed the MDP5 driver to look for the interconnect paths
> in the MDSS device rather than in the MDP5 device itself. This was left
> unnoticed since on my testing devic
Hi Takashi,
Am 04.08.22 um 09:58 schrieb Takashi Iwai:
Hi,
this is a series of fixes for UDL driver to address the leftover URBs
at suspend/resume. It begins with the simplification of FIFO control
code with the standard wait queue, followed by the handling of pending
URBs, and replace BUG_ON(
The commit 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master
components") changed the MDP5 driver to look for the interconnect paths
in the MDSS device rather than in the MDP5 device itself. This was left
unnoticed since on my testing devices the interconnects probably didn't
reach the sync stat
On Thu, Aug 04, 2022 at 11:22:26AM +0200, Jiri Slaby wrote:
> On 04. 08. 22, 10:44, Helge Deller wrote:
> > On 8/4/22 09:15, Helge Deller wrote:
> > > On 8/4/22 07:47, Jiri Slaby wrote:
> > > > On 30. 07. 22, 20:49, Helge Deller wrote:
> > > > > The line and column numbers for the selection need to
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: ChiYuan Huang
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current s
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: ChiaEn Wu
>
> MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> driver, display bias voltage supply, one general purpose LDO, and the
> USB T
On Fri, Aug 5, 2022 at 3:44 AM Biju Das wrote:
>
> Hi Adam and all,
>
> > Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
> >
> > On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> > wrote:
> > >
> > > On Thu, 4 Aug 2022 at 13:51, Marco Felsch
> > wrote:
> > > >
> > > > Hi Dave,
> > > >
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: ChiaEn Wu
>
> MediaTek MT6370 is a SubPMIC consisting of a single cell battery charger
> with ADC monitoring, RGB LEDs, dual channel flashlight, WLED backlight
> driver, display bias voltage supply, one general purpose LDO, and the
> USB T
On Fri, Aug 5, 2022 at 9:07 AM ChiaEn Wu wrote:
>
> From: ChiYuan Huang
>
> The MediaTek MT6370 is a highly-integrated smart power management IC,
> which includes a single cell Li-Ion/Li-Polymer switching battery
> charger, a USB Type-C & Power Delivery (PD) controller, dual
> Flash LED current s
On Fri, 5 Aug 2022 10:24:25 +0100
Tvrtko Ursulin wrote:
> On 05/08/2022 10:08, Andi Shyti wrote:
> > Hi Randy,
> >
> >>> +/**
> >>> + * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> >>> + * @gt: GT structure
> >>
> >> In multiple places (here and below) it would be nice to
Hello Odded
This is a sample (wip) driver for a DSP found on Toshiba Visconti SoC.
The DSP typically accepts some images, apply an algorithm on them and yields
resulting one.
Therefore (image-in, image-out), they say this driver should be classified to
media driver category.
However, it can hand
Convert all the connectors that use cached connector edid and
detect_edid to drm_edid.
Since drm_get_edid() calls drm_connector_update_edid_property() while
drm_edid_read*() do not, we need to call drm_edid_connector_update()
separately, in part due to the EDID caching behaviour in HDMI and
DP. Es
Try to use struct drm_edid where possible, even if having to fall back
to looking into struct edid down low via drm_edid_raw().
v2: Rebase
Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 19 ++-
drivers/gpu/drm/i915/display/
On Tue, Aug 2, 2022 at 9:21 PM ayaka wrote:
>
> Sorry, the previous one contains html data.
>
> > On Aug 2, 2022, at 3:33 PM, Tomasz Figa wrote:
> >
> > On Mon, Aug 1, 2022 at 8:43 PM ayaka wrote:
> >> Sent from my iPad
> On Aug 1, 2022, at 5:46 PM, Tomasz Figa wrote:
> >>> CAUTION: Emai
...
> * NOTE:
> * This file is gcc-parsable HW gospel, coming straight from HW engineers.
I never trust hardware engineers to write code :-)
(Although at the moment they trust me to write VHDL...)
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
On 05/08/2022 10:08, Andi Shyti wrote:
Hi Randy,
+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
In multiple places (here and below) it would be nice to know what a
GT structure is. I looked thru multiple C and header files yesterday
and didn't f
On 04/08/2022 09:59, Arunpravin Paneer Selvam wrote:
Implemented a new intersect and compatible callback function
fetching start offset from drm buddy allocator.
v3: move the bits that are specific to buddy_man (Matthew)
v4: consider the block size /range (Matthew)
Signed-off-by: Christian Köni
Hi Randy,
> > +/**
> > + * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> > + * @gt: GT structure
>
> In multiple places (here and below) it would be nice to know what a
> GT structure is. I looked thru multiple C and header files yesterday
> and didn't find any comments about it
Hi Rodrigo,
On Thu, 4 Aug 2022 13:33:06 -0400
Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> Here goes drm-intel-next-fixes-2022-08-04:
>
> - disable pci resize on 32-bit systems (Nirmoy)
> - don't leak the ccs state (Matt)
> - TLB invalidation fixes (Chris)
>
> Thanks,
> Rodrigo.
>
> The fol
Hi Adam and all,
> Subject: Re: imx8mm lcdif->dsi->adv7535 no video, no errors
>
> On Thu, Aug 4, 2022 at 9:52 AM Dave Stevenson
> wrote:
> >
> > On Thu, 4 Aug 2022 at 13:51, Marco Felsch
> wrote:
> > >
> > > Hi Dave,
> > >
> > > On 22-08-04, Dave Stevenson wrote:
> > > > Hi Marco
> > > >
> > >
On Fri, 05 Aug 2022, Rex-BC Chen wrote:
> On Tue, 2022-08-02 at 17:11 +0300, Jani Nikula wrote:
>> On Wed, 27 Jul 2022, Bo-Chen Chen wrote:
>> > From: Guillaume Ranquet
>> >
>> > This patch adds two helper functions that extract the frequency and
>> > word
>> > length from a struct cea_sad.
>>
From: Alice Chen
Add MediaTek MT6370 flashlight binding documentation.
Reviewed-by: Krzysztof Kozlowski
Signed-off-by: Alice Chen
Signed-off-by: ChiaEn Wu
---
.../bindings/leds/mediatek,mt6370-flashlight.yaml | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
From: Alice Chen
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual Flash
LED current sources, a RGB LED driver, a backlight WLED driver,
a display bias
From: ChiYuan Huang
This adds support for the MediaTek MT6370 SubPMIC. MediaTek MT6370 is a
SubPMIC consisting of a single cell battery charger with ADC monitoring,
RGB LEDs, dual channel flashlight, WLED backlight driver, display bias
voltage supply, one general purpose LDO, and the USB Type-C &
From: ChiYuan Huang
The MediaTek MT6370 is a highly-integrated smart power management IC,
which includes a single cell Li-Ion/Li-Polymer switching battery
charger, a USB Type-C & Power Delivery (PD) controller, dual
Flash LED current sources, a RGB LED driver, a backlight WLED driver,
a display b
Hi all,
Can you guys please review and comment for any changes.
Regards
Suniel
On Mon, Jul 11, 2022 at 3:27 PM Suniel Mahesh
wrote:
> This patch series adds the R16-Vista-E board from RenewWorldOutreach based
> on allwinner R16(A33).
>
> Patch 1/2 adds the dt-bindings for the board.
>
> Patch
Hi all,
Can you guys please review and comment for any changes.
Regards
Suniel
On Mon, Jul 11, 2022 at 3:27 PM Suniel Mahesh
wrote:
> Add a binding for the RenewWorldOutReach R16-Vista-E board based on
> allwinner R16.
>
> Signed-off-by: Suniel Mahesh
> Signed-off-by: Jagan Teki
> Signed-off
1 - 100 of 112 matches
Mail list logo
