Hi all,
On Wed, 26 Aug 2020 10:18:53 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got conflicts in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> drive
On Tue, Sep 1, 2020 at 8:41 AM Rob Clark wrote:
>
> From: Rob Clark
>
> This reduces the spam in dmesg when we start hitting the shrinker, and
> replaces it with something we can put on a timeline while profiling or
> debugging system issues.
That is a good solution,
Reviewed-by: Kristian H. Kr
On Wed, Sep 02, 2020 at 09:17:02PM +0800, Bernard wrote:
> In function drm_atomic_helper_shutdown, maybe there is no need
> to protect DRM_ERROR log in DRM_MODESET_LOCK_ALL_BEGIN &
> DRM_MODESET_LOCK_ALL_END. This change is to make code run a bit
> fast.
>
> Signed-off-by: Bernard Zhao
This is o
ср, 2 сент. 2020 г. в 19:46, Jernej Škrabec :
>
> Dne sreda, 02. september 2020 ob 09:01:17 CEST je Roman Stratiienko
> napisal(a):
> > ср, 2 сент. 2020 г. в 00:58, Jernej Skrabec :
> > > Function sun8i_vi_layer_get_csc_mode() is supposed to return CSC mode
> > > but due to inproper return type (bo
On 9/2/2020 3:38 PM, Nathan Chancellor wrote:
[snip]
Hello Nathan,
Can you tell me how much memory your RPI has and if all of it is
This is the 4GB version.
accessible by the PCIe device? Could you also please include the DTS
of the PCIe node? IIRC, the RPI firmware does some mangling o
Hi Stephen, Mike,
On Tue, Sep 01, 2020 at 01:07:56PM +0900, Hoegeun Kwon wrote:
> To use QHD or higher, we need to modify the pixel_bvb_clk value. So
> add register to control this clock.
>
> Signed-off-by: Hoegeun Kwon
Reviewed-by: Maxime Ripard
Can you merge this patch through the clk tree?
On Tue, Sep 01, 2020 at 06:31:07PM +0200, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 01.09.20 um 11:58 schrieb Maxime Ripard:
> > Hi Stefan
> >
> > On Tue, Aug 25, 2020 at 11:30:58PM +0200, Stefan Wahren wrote:
> >> Am 25.08.20 um 17:06 schrieb Maxime Ripard:
> >>> Hi Stefan,
> >>>
> >>> On Wed, Jul
Hi Hoegeun
On Fri, Aug 21, 2020 at 04:18:34PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
>
> Thank you for your version 4 patch.
> I tested all 78 patches based on the next-20200708.
>
>
> Dual HDMI opearation does not work normally.
> flip_done timed out occurs and doesn't work.
> Could you check
On Wed, Sep 02, 2020 at 03:32:20PM +0200, Maxime Ripard wrote:
> Hi Hoegeun
>
> On Fri, Aug 21, 2020 at 04:18:34PM +0900, Hoegeun Kwon wrote:
> > Hi Maxime,
> >
> > Thank you for your version 4 patch.
> > I tested all 78 patches based on the next-20200708.
> >
> >
> > Dual HDMI opearation does
Hi!
On Wed, Jul 29, 2020 at 04:02:06PM +0100, Dave Stevenson wrote:
> Hi Maxime
>
> On Wed, 8 Jul 2020 at 18:42, Maxime Ripard wrote:
> >
> > The vc4 atomic commit loop has an handrolled loop that is basically
> > identical to for_each_new_crtc_state, let's convert it to that helper.
> >
> > Sig
Hi all,
Some time ago, I asked some questions about how to handle issues with
DRM drivers attempting to touch eDP while muxed away, due to implicit
assumptions about eDP being permanently connected. I've proposed some
changes which prevent eDP access on switched-away eDP outputs for at
least
Hi David Airlie，
Please help to confirm whether this modification is reasonable when
you are free, thanks.
在 2020/8/13 14:31, Huang Jiachai 写道:
ping...
在 2020/7/23 3:01, Heiko Stübner 写道:
Am Dienstag, 7. Juli 2020, 13:25:26 CEST schrieb Sandy Huang:
don't mask possible_crtcs if remote
In function drm_atomic_helper_shutdown, maybe there is no need
to protect DRM_ERROR log in DRM_MODESET_LOCK_ALL_BEGIN &
DRM_MODESET_LOCK_ALL_END. This change is to make code run a bit
fast.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/drm_atomic_helper.c | 4 +---
1 file changed, 1 insertion(
Hi,
On Tue, Sep 01, 2020 at 08:21:36PM +0900, Chanwoo Choi wrote:
> Hi Maxime,
>
> On 7/9/20 2:41 AM, Maxime Ripard wrote:
> > In order to prevent timeouts and stalls in the pipeline, the core clock
> > needs to be maxed at 500MHz during a modeset on the BCM2711.
> >
> > Reviewed-by: Eric Anholt
Some upcoming notebook designs utilize display muxes driven by a
pair of ACPI methods, MXDM to query and configure the operational
mode of the mux (integrated only, discrete only, hybrid non-muxed,
hybrid with dynamic mux switching), and MXDS to query and set the
mux state when running in dynamic s
On Wed, Sep 02, 2020 at 05:36:29PM -0700, Florian Fainelli wrote:
>
>
> On 9/2/2020 3:38 PM, Nathan Chancellor wrote:
> [snip]
> > > Hello Nathan,
> > >
> > > Can you tell me how much memory your RPI has and if all of it is
> >
> > This is the 4GB version.
> >
> > > accessible by the PCIe devi
In function via_mem_alloc`s error branch, DRM_ERROR is protected
in the mutex_lock(&dev->struct_mutex) area.
>From the code, we see that DRM_ERROR is just an error log print
without any struct element, there is no need to protect this.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/via/via_mm.c
On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> The new field 'dma_range_map' in struct device is used to facilitate the
> use of single or multiple offsets between mapping regions of cpu addrs and
> dma addrs. It subsumes the role of "dev->dma_pfn_offset" which was only
> capable o
Dne sreda, 02. september 2020 ob 09:01:17 CEST je Roman Stratiienko
napisal(a):
> ср, 2 сент. 2020 г. в 00:58, Jernej Skrabec :
> > Function sun8i_vi_layer_get_csc_mode() is supposed to return CSC mode
> > but due to inproper return type (bool instead of u32) it returns just 0
> > or 1. Colors are
Hi Tomi,
>-Original Message-
>From: Tomi Valkeinen
>Sent: Tuesday, September 1, 2020 2:05 PM
>To: Swapnil Kashinath Jakhade ; airl...@linux.ie;
>dan...@ffwll.ch; laurent.pinch...@ideasonboard.com; robh...@kernel.org;
>a.ha...@samsung.com; narmstr...@baylibre.com; jo...@kwiboo.se;
>jernej.
On Wed, Sep 02, 2020 at 06:11:08PM -0400, Jim Quinlan wrote:
> On Wed, Sep 2, 2020 at 5:53 PM Nathan Chancellor
> wrote:
> >
> > On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> > > The new field 'dma_range_map' in struct device is used to facilitate the
> > > use of single or multip
Hi Dave & Daniel -
drm-intel-fixes-2020-09-03:
drm/i915 fixes for v5.9-rc4:
- Clang build warning fix
- HDCP fixes
BR,
Jani.
The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:
Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)
are available in the Git repository at:
git
On Wed, Sep 02, 2020 at 12:50:18PM -0500, Daniel Dadap wrote:
> Hi all,
>
>
> Some time ago, I asked some questions about how to handle issues with DRM
> drivers attempting to touch eDP while muxed away, due to implicit
> assumptions about eDP being permanently connected. I've proposed some
> cha
On 26.07.2020 22:33, Sam Ravnborg wrote:
> Prepare the tc358764 bridge driver for use in a chained setup by
> replacing direct use of drm_panel with drm_panel_bridge support.
>
> The bridge panel will use the connector type reported by the panel,
> where the connector for this driver hardcodes DR
https://bugzilla.kernel.org/show_bug.cgi?id=209129
Borislav Petkov (b...@alien8.de) changed:
What|Removed |Added
Component|x86-64 |Video(DRI - non Intel)
Hi Andrzej,
On Thu, Sep 03, 2020 at 11:40:58AM +0200, Andrzej Hajda wrote:
> On 26.07.2020 22:33, Sam Ravnborg wrote:
> > Prepare the tc358764 bridge driver for use in a chained setup by
> > replacing direct use of drm_panel with drm_panel_bridge support.
> >
> > The bridge panel will use the conn
https://bugzilla.kernel.org/show_bug.cgi?id=209129
--- Comment #12 from Laszlo (laszlo.a.t...@googlemail.com) ---
Ok, then what shall I do?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri
Hi All,
So the bug-fix which prompted v8, lead to some discussion about the pwm-lpss
suspend/resume code. So as discussed this version drops the following 2
patches:
[PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on
resume
[PATCH v8 07/17] pwm: lpss: Always update state
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input cl
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter ove
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSA
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set i
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans de
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64
Cha
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clo
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the m
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
The BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use do_div when calculating level because pwm_state.period and .duty_cy
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which grea
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enable
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested f
Before this commit pwm_lpss_apply() was making 2 assuming
2 pre-conditions were met by the existing hardware state:
1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the des
PWM controller drivers should not restore the PWM state on resume. The
convention is that PWM consumers do this by calling pwm_apply_state(),
so that it can be done at the exact moment when the consumer needs
the state to be stored, avoiding e.g. backlight flickering.
The only in kernel consumers
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastse
On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:
> Before this commit pwm_lpss_apply() was making 2 assuming
> 2 pre-conditions were met by the existing hardware state:
I think that "making 2" is too much.
>
> 1. That the base-unit and on-time-div read back from the
> control regis
https://bugzilla.kernel.org/show_bug.cgi?id=209129
--- Comment #13 from Borislav Petkov (b...@alien8.de) ---
> Ok, then what shall I do?
Did you not read this?
"What you could do for starters is try the latest kernel 5.8 to check whether
this has been fixed in the meantime."
--
You are receivi
On Thu, Sep 03, 2020 at 12:51:04PM +0200, Hans de Goede wrote:
> PWM controller drivers should not restore the PWM state on resume. The
> convention is that PWM consumers do this by calling pwm_apply_state(),
> so that it can be done at the exact moment when the consumer needs
> the state to be sto
Hi,
On 9/3/20 12:59 PM, Thierry Reding wrote:
On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:
Before this commit pwm_lpss_apply() was making 2 assuming
2 pre-conditions were met by the existing hardware state:
I think that "making 2" is too much.
You're right at first the sen
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSA
Hi All,
Here is hopefully the last version of this series, as everything seems
to be ready for merging this now.
The only difference from v9 is correcting some mistakes in the commit-msg of:
[PATCH v10 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on hardware state
I plan is to push the entir
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input cl
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clo
PWM controller drivers should not restore the PWM state on resume. The
convention is that PWM consumers do this by calling pwm_apply_state(),
so that it can be done at the exact moment when the consumer needs
the state to be stored, avoiding e.g. backlight flickering.
The only in kernel consumers
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enable
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter ove
Before this commit pwm_lpss_apply() was assuming 2 pre-conditions
were met by the existing hardware state:
1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the desired valu
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which grea
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested f
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set i
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans de
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use do_div when calculating level because pwm_state.period and .duty_cy
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the m
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
The BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastse
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64
Cha
Hi Milind,
On 03/09/2020 09:22, Milind Parab wrote:
> Also, note that CDNS MHDP implements DP_FRAMER_TU_p where bits 5:0 is
> tu_valid_symbols. So max programmable value is 63.
> Register document gives following explanation
> "Number of valid symbols per Transfer Unit (TU). Rounded down to low
https://bugzilla.kernel.org/show_bug.cgi?id=209129
--- Comment #14 from Laszlo (laszlo.a.t...@googlemail.com) ---
Then please assign a person at the mentioned new thread who can examine the
reason of this bug, verify the root cause, assess whether they have fixed it or
not.
Then he can suggest th
Hello Joe,
On Wed, 26 Aug 2020 at 20:38, Christian König wrote:
>
> Am 25.08.20 um 06:56 schrieb Joe Perches:
> > Use semicolons and braces.
> >
> > Signed-off-by: Joe Perches
>
> Acked-by: Christian König
FWIW,
Acked-by: Sumit Semwal
>
> > ---
> > drivers/dma-buf/st-dma-fence.c | 7 +--
On Wed, Sep 2, 2020 at 5:53 PM Nathan Chancellor
wrote:
>
> On Mon, Aug 24, 2020 at 03:30:20PM -0400, Jim Quinlan wrote:
> > The new field 'dma_range_map' in struct device is used to facilitate the
> > use of single or multiple offsets between mapping regions of cpu addrs and
> > dma addrs. It su
On Tue, Sep 1, 2020 at 4:24 AM Christoph Hellwig wrote:
>
> I've applied this to the dma-mapping tree.
>
> I had to resolve a conflict in drivers/of/address.c with a recent
> mainline commit. I also applied the minor tweaks Andy pointed out
> plus a few more style changes. A real change is that
Hi,
On 9/3/20 2:56 PM, Andy Shevchenko wrote:
On Thu, Sep 03, 2020 at 03:48:16PM +0300, Andy Shevchenko wrote:
On Thu, Sep 03, 2020 at 01:23:27PM +0200, Hans de Goede wrote:
the question is do we need to have similar in acpi_lpss.c?
For example,
static const struct lpss_device_desc b
Since all we do with scatterlists is map them in the MMU, we don't have
any hardware constraints on how they're laid out. Let the DMA layer know
so it won't warn when DMA API debugging is enabled.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 1 +
1 file changed, 1 in
On 03/09/2020 14:59, Robin Murphy wrote:
Since all we do with scatterlists is map them in the MMU, we don't have
any hardware constraints on how they're laid out. Let the DMA layer know
so it won't warn when DMA API debugging is enabled.
Signed-off-by: Robin Murphy
Reviewed-by: Steven Price
On Wed, Sep 02, 2020 at 09:26:27AM +0200, Daniel Vetter wrote:
> Following functions are only used internally, not by drivers:
> - devm_drm_dev_init
>
> Also, now that we have a very slick and polished way to allocate a
> drm_device with devm_drm_dev_alloc, update all the docs to reflect the
> new
Hi Laurent,
On 03.09.2020 11:59, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Thu, Sep 03, 2020 at 11:40:58AM +0200, Andrzej Hajda wrote:
>> On 26.07.2020 22:33, Sam Ravnborg wrote:
>>> Prepare the tc358764 bridge driver for use in a chained setup by
>>> replacing direct use of drm_panel with drm_
On Sun, Aug 30, 2020 at 2:40 AM Krzysztof Kozlowski wrote:
>
> Additional properties or nodes actually might appear (e.g. operating
> points table) so use unevaluatedProperties to fix dtbs_check warnings
> like:
>
> arch/arm/boot/dts/exynos4210-i9100.dt.yaml: gpu@1300:
> 'opp_table' does
On 01.09.20 10:33, Roger Pau Monne wrote:
To be used in order to create foreign mappings. This is based on the
ZONE_DEVICE facility which is used by persistent memory devices in
order to create struct pages and kernel virtual mappings for the IOMEM
areas of such devices. Note that on kernels with
(Including a bunch more emails in the To: that got missed the first time)
Hello everyone!
The X.org board is soliciting proposals to host XDC in 2021. Since
XDC2020 is being held virtually this year, we've decided to host in
either North America or Europe. However, the board is open to other
loca
On Sat, Aug 29, 2020 at 04:24:52PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. assigned-clocks) so
> use unevaluatedProperties to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml:
> system-controller@105c:
> 'a
On Sat, Aug 29, 2020 at 04:24:54PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. clocks) so use
> unevaluatedProperties to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: timer@101c:
> 'clock-names', 'clocks' do
On Sat, Aug 29, 2020 at 04:24:53PM +0200, Krzysztof Kozlowski wrote:
> Additional properties or nodes actually might appear (e.g. operating
> points table) so use unevaluatedProperties to fix dtbs_check warnings
> like:
>
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac:
> '
On Sat, Aug 29, 2020 at 04:24:57PM +0200, Krzysztof Kozlowski wrote:
> Additional properties actually might appear (e.g. power-domains) so use
> unevaluatedProperties to fix dtbs_check warnings like:
>
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: i2s@1144:
> Additional properties
On Tue, Sep 01, 2020 at 03:50:00PM +0100, Mark Brown wrote:
> On Sat, 29 Aug 2020 16:24:52 +0200, Krzysztof Kozlowski wrote:
> > Additional properties actually might appear (e.g. assigned-clocks) so
> > use unevaluatedProperties to fix dtbs_check warnings like:
> >
> > arch/arm64/boot/dts/exynos
On Sun, Aug 30, 2020 at 01:30:02PM +0200, Krzysztof Kozlowski wrote:
> Additional properties or nodes actually might appear (e.g. power
> domains) so use unevaluatedProperties to fix dtbs_check warnings like:
>
> arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281:
> 'iommus', 'powe
If other drivers use the exynos_dsi driver as a bridge, they might bring
their own encoder. Enable and disable the MIPI-DSI bridge using the
bridge functions instead of the encoder functions.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 33 +++-
As the driver is not platform dependent anymore, move it to the drm
bridge driver directory.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/bridge/Kconfig|7 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/samsung-dsim.c | 1797 +++
The bridge will not necessarily use the encoder of struct exynos_dsi,
but might use another encoder from another drm driver. Therefore, the
driver has to use the encoder from the bridge instead of the one from
exynos_dsi.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c
The phy timings are already shifted to the field position. If the driver
is reused on multiple platforms, this exposes the field positions to the
platform code.
Store only the timing values in the platform data and shift the value to
the field when writing the fields to the registers.
Signed-off-
The tearing effect interrupts are not handled by the MIPI DSI bridge
driver, but the display controller driver.
Allow platforms to register a callback for the tearing effect interrupt.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 19 ---
1 file ch
The bind/unbind API will be only used with the component framework, but
the mipi dsi host is always required. Therefore, move it to the shared
probe helper function.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 10 +++---
1 file changed, 7 insertions(+), 3 del
Split the driver into the drm bridge driver and the exynos platform
specific driver.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/Makefile | 2 +-
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 312 ++
drivers/gpu/drm/exynos/exynos_drm_dsi.h |
Different revisions of the MIPI-DSI PHY have slightly different register
layouts. Currently, the register layout was stored per platform, which
makes it necessary to define the layout for each new platform.
Keep the register layout in the driver and use identifiers to specify
which register layout
As the driver shall be usable with drivers that use the component
framework and drivers that don't, split the common probing code into a
separate function that can be called from different locations.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 54 ++--
Display controllers need to know if the MIPI DSI bridge is running in
command or video mode. Allow platform drivers to register a callback for
being notified about the used mode.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 24 ++--
1 file chan
Hello,
the Exynos MIPI DSI Phy is also found on the i.MX8M Mini. However, on the
i.MX8M Mini, the bridge is driven by an LCDIF display controller instead of
the Exynos Decon. The driver for the LCDIF does not use the component
framework, but uses drm bridges.
This series converts the Exynos MIPI
In commit 05193dc38197 ("drm/bridge: Make the bridge chain a
double-linked list") the bridge has been removed and replaced by a
private field. Remove the leftover documentation of the removed field.
Signed-off-by: Michael Tretter
---
include/drm/drm_encoder.h | 1 -
1 file changed, 1 deletion(-)
Use the exynos_dsi as drvdata instead of the encoder to further decouple
the driver from the encoder.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exy
The driver uses the encoder to get the mode that shall be configured.
This is not possible, if the driver is used as a bridge, because the
encoder might not be used.
Use the mode_set function to get the display mode.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1
1 - 100 of 152 matches
Mail list logo
