Am 01.06.24 um 10:45 schrieb Zhaoxiong Lv:
Hi Zhaoxiong,
The bias IC of this kindisplay-kd101ne3 panel is placed
on the panel side, so when the panel is powered on,
there is no need to control AVDD and AVEE in the driver,
only 3.3v and reset are needed.
Signed-off-by: Zhaoxiong Lv
---
Chage
On Mon, May 27 2024 at 20:11:49 -03:00:00, Val Packett
wrote:
The RK3066 VOP sets a dma_stop bit when it's done scanning out a frame
and needs the driver to acknowledge that by clearing the bit.
So unless we clear it "between" frames, the RGB output only shows
noise
instead of the
On Sat, Jun 1, 2024 at 11:33 PM wrote:
>
> s=20181004; d=freemail.hu;
>
> h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding;
> l=6462; bh=CnHSqkRX34kqCWN2/oPtvm9wm8HJCe8QhPwQypdpi3w=;
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Adrián Larumbe (1):
meson: make build system happy by replacing deprecated feature
David Heidelberg (1):
include poll.h instead of sys/poll.h
David Rosca (1):
amdgpu: Make amdgpu_device_deinitialize thread-safe
Dylan Baker (2):
Hi Cristian,
kernel test robot noticed the following build errors:
[auto build test ERROR on 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0]
url:
https://github.com/intel-lab-lkp/linux/commits/Cristian-Ciocaltea/drm-bridge-dw-hdmi-Simplify-clock-handling/20240601-211531
base:
On 01/06/24 00:01, Randy Dunlap wrote:
> Hi,
>
> On 5/31/24 10:12 AM, Devarsh Thakkar wrote:
>> Add documentation for rounding, scaling, absolute value and difference,
>> 32-bit division related macros and functions exported by math.h header
>> file.
>>
>
> I don't see any kernel-doc for
On Sat, Jun 01, 2024 at 04:12:22PM +0300, Cristian Ciocaltea wrote:
> The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
> Synopsys DesignWare HDMI TX controller used in the previous SoCs.
>
> It is HDMI 2.1 compliant and supports the following features, among
> others:
>
> *
On Sat, Jun 01, 2024 at 04:45:25PM +0800, Zhaoxiong Lv wrote:
> Create a new dt-scheam for the kd101ne3-40ti.
> The bias IC of this kindisplay-kd101ne3 panel is placed
> on the panel side, so when the panel is powered on,
> there is no need to control AVDD and AVEE in the driver.
>
>
On Sat, Jun 01, 2024 at 04:45:28PM +0800, Zhaoxiong Lv wrote:
> This Starry panel has the same timing as the Kingdisplay panel,
> so add starry configuration in the Kingdisplay driver.
Do these two panels share the same driver IC? Programming sequences do
not seem common, so it might be better to
On Sat, Jun 01, 2024 at 04:45:26PM +0800, Zhaoxiong Lv wrote:
> The bias IC of this kindisplay-kd101ne3 panel is placed
> on the panel side, so when the panel is powered on,
> there is no need to control AVDD and AVEE in the driver,
> only 3.3v and reset are needed.
>
> Signed-off-by: Zhaoxiong
On 01/06/2024 10:45, Zhaoxiong Lv wrote:
> The Starry-er88577 is a 10.1" WXGA TFT-LCD panel, which fits
> in nicely with the existing panel-kingdisplay-kd101ne3 driver.
> Hence, we add a new compatible with panel specific config.
>
> Signed-off-by: Zhaoxiong Lv
> ---
>
> Chage since V2:
>
On 01/06/2024 10:45, Zhaoxiong Lv wrote:
> Create a new dt-scheam for the kd101ne3-40ti.
> The bias IC of this kindisplay-kd101ne3 panel is placed
> on the panel side, so when the panel is powered on,
> there is no need to control AVDD and AVEE in the driver.
> +
> + reg:
> +description: the
Hi Cristian,
kernel test robot noticed the following build errors:
[auto build test ERROR on 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0]
url:
https://github.com/intel-lab-lkp/linux/commits/Cristian-Ciocaltea/drm-bridge-dw-hdmi-Simplify-clock-handling/20240601-211531
base:
The VFP, HBP, and HSA are divided between the available lanes if
there is more than one lane. For certain timings and lane
configurations, the HFP may not be evenly divisible. If the HFP
is rounded down, it ends up being too small which can cause some
monitors to not sync properly. In these
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 available
on the i.MX8M[MNP] than what was possible.
As noted by
Hi Cristian,
a few drive-by comments below.
Sam
> +
> +static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
> + .fill_modes = drm_helper_probe_single_connector_modes,
> + .detect = dw_hdmi_connector_detect,
> + .destroy = drm_connector_cleanup,
> +
In the process of adding support for shared IRQ pins, a scenario
was accidentally created where adv7511_irq_process returned
prematurely causing the EDID to fail randomly.
Since the interrupt handler is broken up into two main helper functions,
update both of them to treat the helper functions as
The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1
Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a
Samsung IP block.
Add just the basic support for now, i.e. RGB output up to 4K@60Hz,
without audio, CEC or any of the HDMI 2.1 specific features.
Make use of devm_clk_get_optional_enabled() to replace devm_clk_get()
and clk_prepare_enable() for ref_clk and drop the now unnecessary calls
to clk_disable_unprepare().
Additionally, use devm_clk_get_optional() helper for grf_clk to replace
the open coding call to devm_clk_get() followed by the
The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller supports
the following features, among others:
* Fixed Rate Link (FRL)
* 4K@120Hz and 8K@60Hz video modes
* Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
Cinema VRR
* Fast Vactive (FVA), aka Quick Frame
The mpll_cfg, cur_ctr and phy_config members in struct dw_hdmi_plat_data
are only used to configure the Synopsys PHYs supported internally by DW
HDMI transmitter driver (gpu/drm/bridge/synopsys/dw-hdmi.c), via
hdmi_phy_configure_dwc_hdmi_3d_tx(), which is further invoked from
dw_hdmi_phy_init().
Document the Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX controller
found on Rockchip RK3588 SoC family.
Since RK3588 uses different clocks than previous Rockchip SoCs and also
requires a couple of reset lines and some additional properties, provide
the required changes in the binding to
The regulators are only enabled at bind() and disabled at unbind(),
hence replace the boilerplate code by making use of
devm_regulator_get_enable() helper.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 34 +
1 file changed, 6
Prefer drm_{err|info|dbg}() over deprecated DRM_DEV_{ERROR|INFO|DEBUG}()
logging macros.
Conversion done with the help of the following semantic patch, followed
by a few minor indentation adjustments:
@@
identifier T;
@@
(
-DRM_DEV_ERROR(T->dev,
+drm_err(T,
...)
|
-DRM_DEV_INFO(T->dev,
In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, factor out the hdmi_data_info setup from
dw_hdmi_setup() into a common dw_hdmi_prep_data() helper.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h | 2
In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, export dw_hdmi_connector_create()
function, while adding a new parameter to allow using a different
drm_connector_funcs structure.
Signed-off-by: Cristian Ciocaltea
---
In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, factor out the AVI infoframe setup from
hdmi_config_AVI() into a common dw_hdmi_prep_avi_infoframe() helper.
Signed-off-by: Cristian Ciocaltea
---
In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, export dw_hdmi_i2c_adapter() while adding
a new parameter to allow using a different i2c_algorithm.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h | 2
In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication, factor out the vmode setup from
hdmi_av_composer() into a common dw_hdmi_prep_vmode() helper.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h | 2 ++
In preparation to add support for the HDMI 2.1 Quad-Pixel TX Controller
and minimize code duplication as much as possible, export all reusable
functions and provide the related declarations and structs within a new
header file.
For consistency, ensure the newly exported symbols share the 'dw_'
Make use of devm_clk_get_enabled() to replace devm_clk_get() and
clk_prepare_enable() for isfr and iahb clocks, and drop the now
unnecessary calls to clk_disable_unprepare().
Similarly, use devm_clk_get_optional_enabled() helper for cec clock,
which additionally allows to remove the -ENOENT test.
The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
Synopsys DesignWare HDMI TX controller used in the previous SoCs.
It is HDMI 2.1 compliant and supports the following features, among
others:
* Fixed Rate Link (FRL)
* 4K@120Hz and 8K@60Hz video modes
* Variable Refresh Rate (VRR)
On Thu, May 30, 2024 at 08:16:12PM +, Mina Almasry wrote:
> Add documentation outlining the usage and details of devmem TCP.
>
> Signed-off-by: Mina Almasry
>
The doc LGTM, thanks!
Reviewed-by: Bagas Sanjaya
--
An old man doll... just what I always wanted! - Clara
signature.asc
On Fri, 31 May 2024 19:56:14 +0300
Andy Shevchenko wrote:
> The driver has no in kernel users and requires a board file
> to be instantiated. Remove basically a dead code.
>
> If ever needed, it can be reinstantiated and converted to one
> that uses firmware node interfaces.
>
> Signed-off-by:
This Starry panel has the same timing as the Kingdisplay panel,
so add starry configuration in the Kingdisplay driver.
Signed-off-by: Zhaoxiong Lv
---
Chage since V2:
- Add compatible for Starry er88577 in panel-kingdisplay-kd101ne3 drivers.
---
.../drm/panel/panel-kingdisplay-kd101ne3.c
The Starry-er88577 is a 10.1" WXGA TFT-LCD panel, which fits
in nicely with the existing panel-kingdisplay-kd101ne3 driver.
Hence, we add a new compatible with panel specific config.
Signed-off-by: Zhaoxiong Lv
---
Chage since V2:
- Add compatible for Starry er88577 in Kingdisplay kd101ne3
The bias IC of this kindisplay-kd101ne3 panel is placed
on the panel side, so when the panel is powered on,
there is no need to control AVDD and AVEE in the driver,
only 3.3v and reset are needed.
Signed-off-by: Zhaoxiong Lv
---
Chage since V2:
- 1. Use the new mipi_dsi_dcs_write_seq_multi()
Create a new dt-scheam for the kd101ne3-40ti.
The bias IC of this kindisplay-kd101ne3 panel is placed
on the panel side, so when the panel is powered on,
there is no need to control AVDD and AVEE in the driver.
Signed-off-by: Zhaoxiong Lv
---
Chage since V2:
- Drop some properties that have
Kingdisplay kd101ne3 and Starry er88577 both 10.1" WXGA TFT LCD panel,
And the two panels have the same timing, so add compatible for Kingdisplay
kd101ne3 and Starry er88577 in dt-bindings and drivers.
Changes in v2:
- PATCH 1/4: Delete some unnecessary information.
- PATCH 2/4: Use the new
Hi Andy,
kernel test robot noticed the following build errors:
[auto build test ERROR on jic23-iio/togreg]
[also build test ERROR on lee-backlight/for-backlight-fixes linus/master
v6.10-rc1 next-20240531]
[cannot apply to lee-backlight/for-backlight-next]
[If your patch is applied to the wrong
Hi Andy,
kernel test robot noticed the following build errors:
[auto build test ERROR on jic23-iio/togreg]
[also build test ERROR on lee-backlight/for-backlight-fixes linus/master
v6.10-rc1 next-20240531]
[cannot apply to lee-backlight/for-backlight-next pavel-leds/for-next]
[If your patch is
The pull request you sent on Sat, 1 Jun 2024 06:46:21 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-06-01
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cc8ed4d0a8486c7472cd72ec3c19957e509dc68c
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, May 31, 2024 at 1:57 AM Andy Shevchenko <
andriy.shevche...@linux.intel.com> wrote:
> On Thu, May 30, 2024 at 10:36:57PM -0700, Chia-I Wu wrote:
> > We can skip children resources when the parent resource does not cover
> > the range.
> >
> > This should help vmf_insert_* users on x86,
On 5/31/2024 8:20 AM, Shuah Khan wrote:
On 5/31/24 00:09, Danish Prakash wrote:
(as part of LFX Linux Mentorship program)
Please add proper commit log for this change.
Looks like a good fix, and I'd love to take it, but the commit log needs
some content.
Signed-off-by: Danish Prakash
Hi Linus,
This is the weekly fixes pull. Lots of small fixes across the board,
one BUG_ON fix in shmem seems most important, otherwise amdgpu, i915,
xe mostly with small fixes to all the other drivers.
Dave.
drm-fixes-2024-06-01:
drm fixes for 6.10-rc2
shmem:
- fix BUG_ON in COW handling
-
Document default DP port preemphasis configurable via new DT property
"toshiba,pre-emphasis". This is useful in case the DP link properties
are known and starting link training from preemphasis setting of 0 dB
is not useful. The preemphasis can be set separately for both DP lanes
in range 0=0dB,
Make the default DP port preemphasis configurable via new DT property
"toshiba,pre-emphasis". This is useful in case the DP link properties
are known and starting link training from preemphasis setting of 0 dB
is not useful. The preemphasis can be set separately for both DP lanes
in range 0=0dB,
The MIPI_DSI_CLOCK_NON_CONTINUOUS causes visible artifacts in high
resolution modes, disable it. Namely, in DSI->DP mode 1920x1200 24
bpp 59.95 Hz, with DSI bus at maximum 1 Gbps per lane setting, the
image contains jittering empty lines.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc:
This line_pixel_subtract is no longer needed now that the bridge can
request and obtain specific pixel clock on input to the bridge, with
clock frequency that matches the Pixel PLL frequency.
The line_pixel_subtract is now always 0, so drop it entirely.
The line_pixel_subtract was not reliable
The only information in the datasheet regarding this divider is a note
in SYS_PLLPARAM register documentation which states that when LSCLK is
270 MHz, LSCLK_DIV should be 1. What should LSCLK_DIV be set to when
LSCLK is 162 MHz (for DP 1.62G mode) is unclear, but empirical test
confirms using
This reverts commit 01338bb82fed40a6a234c2b36a92367c8671adf0.
With clock improvements in place, this seems to be no longer
necessary. Set the CLRSIPO to default setting recommended by
manufacturer.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej
Use tc_pxl_pll_calc() to find out the exact clock frequency generated by the
Pixel PLL. Use the Pixel PLL frequency as adjusted_mode clock frequency and
pass it down the display pipeline to obtain exactly this frequency on input
into this bridge.
The precise input frequency that matches the Pixel
Split tc_pxl_pll_en() into tc_pxl_pll_calc() which does only Pixel PLL
parameter calculation and tc_pxl_pll_en() which calls tc_pxl_pll_calc()
and then configures the Pixel PLL register.
This is a preparatory patch for further rework, where tc_pxl_pll_calc()
will also be used to find out the
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_chain_mode_fixup.
The patches was already rb / ab - but due to the age
From: Sam Ravnborg
The mode_valid implementation had a call to
drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
not allowed to change anything - only to validate the mode.
As the next bridge is often/always a connector the call had no effect
anyway. So drop it.
>From the
From: Sam Ravnborg
There are no users left of drm_bridge_chain_mode_fixup() and we
do not want to have this function available, so drop it.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Reviewed-by: Laurent Pinchart
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc:
drm_crtc_helper_funcs::atomic_disable can be called even when the CRTC is
still enabled. This can occur when the mode changes or the CRTC is set as
inactive.
In the case where the CRTC is being set as inactive we only want to
blank the screen. The Screen Target should remain intact as long as the
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.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc:
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.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Keep the list sorted numerically. No functional change.
Signed-off-by: Marek Vasut
---
Cc: Andrzej Hajda
Cc: Conor Dooley
Cc: Daniel Vetter
Cc: David Airlie
Cc: Jernej Skrabec
Cc: Jonas Karlman
Cc: Krzysztof Kozlowski
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Maarten Lankhorst
Cc:
In case an upstream bridge modified the required clock frequency
in its .atomic_check callback by setting adjusted_mode.clock ,
make sure that clock frequency is generated by the LCDIFv3 block.
This is useful e.g. when LCDIFv3 feeds DSIM which feeds TC358767
with (e)DP output, where the TC358767
Use connector->display_info.is_hdmi instead of manually using
drm_detect_hdmi_monitor().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c| 2 +-
drivers/gpu/drm/msm/hdmi/hdmi.h| 2 --
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 11 ---
3 files changed,
Setup the HDMI connector on the MSM HDMI outputs. Make use of
atomic_check hook and of the provided Infoframe infrastructure.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/Kconfig| 2 +
drivers/gpu/drm/msm/hdmi/hdmi.c| 44 ++---
The mode_set callback is deprecated, it doesn't get the
drm_bridge_state, just mode-related argumetns. Turn it into the
atomic_enable callback as suggested by the documentation.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 33 ++---
1
This patchset sits on top Maxime's HDMI connector patchset ([1]).
Currently this is an RFC exploring the interface between HDMI bridges
and HDMI connector code. This has been lightly verified on the Qualcomm
DB820c, which has native HDMI output. If this approach is considered to
be acceptable,
Extend the driver to send SPD and HDMI Vendor Specific InfoFrames.
While the HDMI block has special block to send HVS InfoFrame, use
GENERIC0 block instead. VENSPEC_INFO registers pack frame data in a way
that requires manual repacking in the driver, while GENERIC0 doesn't
have such format
The GENERIC0_UPDATE field is a single bit. Redefine it as boolean to
simplify its usage in the driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/registers/display/hdmi.xml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Turn drm_bridge_connector to using drmm_kzalloc() and
drmm_connector_init() and drop the custom destroy function. The
drm_connector_unregister() and fwnode_handle_put() are already handled
by the drm_connector_cleanup() and so are safe to be dropped.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry
Change MSM HDMI bridge to use atomic_* callbacks in preparation to
enablign the HDMI connector support.
Acked-by: Maxime Ripard
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git
In order to let bridge chains implement HDMI connector infrastructure,
add necessary glue code to the drm_bridge_connector. In case there is a
bridge that sets DRM_BRIDGE_OP_HDMI, drm_bridge_connector will register
itself as a HDMI connector and provide proxy drm_connector_hdmi_funcs
Allow passing NULL as audio infoframe as a way to disable Audio
Infoframe generation.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git
On Sun, Mar 10, 2024 at 11:04:00PM +0100, 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: Tobias Jakobi
> ---
>
On Fri, May 31, 2024 at 12:20:24PM -0700, Abhinav Kumar wrote:
>
>
> On 5/31/2024 1:16 AM, Dmitry Baryshkov wrote:
> > On Fri, 31 May 2024 at 04:02, Abhinav Kumar
> > wrote:
> > >
> > >
> > >
> > > On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
> > > > Max upscale / downscale factors are
On 5/31/2024 1:16 AM, Dmitry Baryshkov wrote:
On Fri, 31 May 2024 at 04:02, Abhinav Kumar wrote:
On 3/13/2024 5:02 PM, Dmitry Baryshkov wrote:
Max upscale / downscale factors are constant between platforms. In
preparation to adding support for virtual planes and allocating SSPP
blocks
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 0e1980c40b6edfa68b6acf926bab22448a6e40c9 Add linux-next specific
files for 20240531
Unverified Error/Warning (likely false positive, please contact us if
interested):
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: Tobias Jakobi
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
On Mon, 27 May 2024, Maxime Ripard wrote:
> Let me know what you think,
Sorry to report that this series generates a bunch of kernel-doc
warnings in include/drm/drm_connector.h. Documenting nested struct
members doesn't work as smoothly as you'd expect:
../include/drm/drm_connector.h:1138:
Hi,
On 5/31/24 10:12 AM, Devarsh Thakkar wrote:
> Add documentation for rounding, scaling, absolute value and difference,
> 32-bit division related macros and functions exported by math.h header
> file.
>
I don't see any kernel-doc for division functions in this header file.
Do some division
Applied. Thanks!
Alex
On Fri, May 31, 2024 at 11:37 AM Randy Dunlap wrote:
>
>
>
> On 5/31/24 2:32 AM, Colin Ian King wrote:
> > There are a few spelling mistakes in dml2_printf messages. Fix them.
> >
> > Signed-off-by: Colin Ian King
>
>
> Reviewed-by: Randy Dunlap
>
> Thanks.
>
> > ---
>
On 5/30/2024 1:22 AM, Ryan Walklin wrote:
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown
OEM used in a number of handheld gaming devices made by Anbernic.
Limited information is available online however the panel timing values
(below) have been obtained from the
On 5/31/2024 11:43 AM, Dmitry Baryshkov wrote:
On Fri, May 31, 2024 at 10:18:07AM -0600, Jeffrey Hugo wrote:
On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote:
There are two ways to describe an eDP panel in device tree. The
recommended way is to add a device on the AUX bus, ideally using the
On Fri, May 31, 2024 at 10:46:28PM +0530, Devarsh Thakkar wrote:
> Add tests for round_closest_up/down and roundclosest macros which round
> to nearest multiple of specified argument. These are tested with kunit
> tool as shared here [1].
>
> [1]:
On Fri, May 31, 2024 at 10:18:07AM -0600, Jeffrey Hugo wrote:
> On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote:
> > There are two ways to describe an eDP panel in device tree. The
> > recommended way is to add a device on the AUX bus, ideally using the
> > edp-panel compatible. The legacy way is to
On Fri, May 31, 2024 at 10:41:36PM +0530, Devarsh Thakkar wrote:
> Add below rounding related macros:
>
> round_closest_up(x, y) : Rounds x to closest multiple of y where y is a
> power of 2, with a preference to round up in case two nearest values are
> possible.
>
> round_closest_down(x, y) :
On Fri, May 31, 2024 at 10:42:20PM +0530, Devarsh Thakkar wrote:
> Add documentation for rounding, scaling, absolute value and difference,
> 32-bit division related macros and functions exported by math.h header
> file.
As long as it renders correctly, fine to me
Reviewed-by: Andy Shevchenko
--
On Fri, May 31, 2024 at 10:43:05PM +0530, Devarsh Thakkar wrote:
> From: Daniel Latypov
>
> Add basic test coverage for files that don't require any config options:
> * part of math.h (what seem to be the most commonly used macros)
> * gcd.c
> * lcm.c
> * int_sqrt.c
> * reciprocal_div.c
>
On Fri, May 31, 2024 at 06:15:46PM +0100, Lee Jones wrote:
> On Fri, 31 May 2024, Andy Shevchenko wrote:
> > On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote:
> > > Driver is quite outdated from the Linux kernel internal APIs
> > > perspective. In particular GPIO code is using
Hi,
On Fri, May 31, 2024 at 9:51 AM Jeffrey Hugo wrote:
>
> On 5/31/2024 10:20 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, May 31, 2024 at 9:18 AM Jeffrey Hugo wrote:
> >>
> >> On 5/30/2024 5:12 PM, Dmitry Baryshkov wrote:
> >>> There are two ways to describe an eDP panel in device tree.
Use generic macro round_closest_up() for rounding closest to specified
value instead of using local macro round_closest().
There is no change from functionality point of view as round_closest_up()
is functionally same as the previously used local macro round_closest().
Signed-off-by: Devarsh
If neither of the flags to round down (V4L2_SEL_FLAG_LE) or round up
(V4L2_SEL_FLAG_GE) are specified by the user, then round to nearest
multiple of requested value while updating the crop rectangle coordinates.
Use the rounding macro which gives preference to rounding down in case two
nearest
On 5/29/2024 10:56 PM, Jun Nie wrote:
Enable compression bit in cfg2 register for DSC in the DSI case
per hardware version.
Signed-off-by: Jun Nie
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Neil Armstrong # on SM8650-QRD
Tested-by: Neil Armstrong # on SM8650-HDK
Reviewed-by:
+Cc: Johan (via kernel.org)
On Fri, May 31, 2024 at 08:14:43PM +0300, Andy Shevchenko wrote:
> On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote:
> > Driver is quite outdated from the Linux kernel internal APIs
> > perspective. In particular GPIO code is using legacy calls,
> > that
On Fri, May 31, 2024 at 06:14:25PM +0100, Lee Jones wrote:
> Making sure Johan is aware of this with his new address.
Right, in any case this is not the final version (a couple of leftovers).
I have mentioned this series in the original thread.
--
With Best Regards,
Andy Shevchenko
Add tests for round_closest_up/down and roundclosest macros which round
to nearest multiple of specified argument. These are tested with kunit
tool as shared here [1].
[1]: https://gist.github.com/devarsht/3f9042825be3da4e133b8f4eda067876
Signed-off-by: Devarsh Thakkar
---
V1->V11 (No change,
On Fri, 31 May 2024, Andy Shevchenko wrote:
> On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote:
> > Driver is quite outdated from the Linux kernel internal APIs
> > perspective. In particular GPIO code is using legacy calls,
> > that started being replaced by a new API ca. 2014,
On Fri, May 31, 2024 at 07:56:12PM +0300, Andy Shevchenko wrote:
> Driver is quite outdated from the Linux kernel internal APIs
> perspective. In particular GPIO code is using legacy calls,
> that started being replaced by a new API ca. 2014, i.e. ten
> years ago.
>
> Suggested-by: Linus Walleij
Making sure Johan is aware of this with his new address.
On Fri, 31 May 2024, Andy Shevchenko wrote:
> Driver is quite outdated from the Linux kernel internal APIs
> perspective. In particular GPIO code is using legacy calls,
> that started being replaced by a new API ca. 2014, i.e. ten
> years
From: Daniel Latypov
Add basic test coverage for files that don't require any config options:
* part of math.h (what seem to be the most commonly used macros)
* gcd.c
* lcm.c
* int_sqrt.c
* reciprocal_div.c
(Ignored int_pow.c since it's a simple textbook algorithm.)
These tests aren't
Add documentation for rounding, scaling, absolute value and difference,
32-bit division related macros and functions exported by math.h header
file.
Signed-off-by: Devarsh Thakkar
---
V11: Fix title for math function header
V10: Patch introduced
V1->V9 (No change)
---
Add below rounding related macros:
round_closest_up(x, y) : Rounds x to closest multiple of y where y is a
power of 2, with a preference to round up in case two nearest values are
possible.
round_closest_down(x, y) : Rounds x to closest multiple of y where y is a
power of 2, with a preference to
1 - 100 of 489396 matches
Mail list logo
