Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of
From: Khaled Almahallawy
Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
v2: uniform bit names TP4a/b/c (Manasi)
Signed-off-by: Khaled Almahallawy
Reviewed-by: Manasi Navare
Tested-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 --
From: Khaled Almahallawy
Add the missing CP2520 pattern 2 and 3 phy compliance patterns
v2: cosemtic changes
Reviewed-by: Manasi Navare (v1)
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
2 files changed, 4
From: Khaled Almahallawy
Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
v2: uniform bit names TP4a/b/c (Manasi)
Signed-off-by: Khaled Almahallawy
Reviewed-by: Manasi Navare
Tested-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 --
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of
From: Khaled Almahallawy
Add the missing CP2520 pattern 2 and 3 phy compliance patterns
v2: cosemtic changes
Reviewed-by: Manasi Navare (v1)
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
2 files changed, 4
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of
From: Khaled Almahallawy
Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
v2: uniform bit names TP4a/b/c (Manasi)
Signed-off-by: Khaled Almahallawy
Reviewed-by: Manasi Navare
Tested-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 --
From: Khaled Almahallawy
Add the missing CP2520 pattern 2 and 3 phy compliance patterns
v2: cosemtic changes
Reviewed-by: Manasi Navare (v1)
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
2 files changed, 4
v2: Rebased patch on top of:
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL
Signed-off-by: Khaled Almahallawy
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/display/intel_dp.c | 81
From: Khaled Almahallawy
Add the missing CP2520 pattern 2 and 3 phy compliance patterns
v2: cosemtic changes
Reviewed-by: Manasi Navare (v1)
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
2 files changed, 4
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of
From: Khaled Almahallawy
Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
v2: uniform bit names TP4a/b/c (Manasi)
Signed-off-by: Khaled Almahallawy
Reviewed-by: Manasi Navare
Tested-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 --
Hi Linus,
Not much going on this week, nouveau has a display hw bug workaround,
amdgpu has some PM fixes and CIK regression fixes, one single radeon
PLL fix, and a couple of i915 display fixes.
Dave.
drm-fixes-2020-09-04:
drm fixes for 5.9-rc4
amdgpu:
- Fix for 32bit systems
- SW CTF fix
-
Hi Tomi,
On Tue, Sep 01, 2020 at 10:46:03AM +0300, Tomi Valkeinen wrote:
> Hi Swapnil,
>
> On 31/08/2020 11:23, Swapnil Jakhade wrote:
>
> > +static int cdns_mhdp_validate_mode_params(struct cdns_mhdp_device *mhdp,
> > + const struct drm_display_mode *mode,
>
Disable the RPTR shadow across all targets. It will be selectively
re-enabled later for targets that need it.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 5 +
drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 10 +
drivers/gpu/drm/msm/adreno/a4xx_gpu.c |
The main a5xx preemption record can be marked as privileged to
protect it from user access but the counters storage needs to be
remain unprivileged. Split the buffers and mark the critical memory
as privileged.
Cc: sta...@vger.kernel.org
Signed-off-by: Jordan Crouse
---
a650 supports expanded apriv support that allows us to map critical buffers
(ringbuffer and memstore) as as privileged to protect them from corruption.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
On Adreno GPUs there is an option to shadow the RPTR register in GPU accessible
memory. The shadow memory allows the kernel driver to query the value of the
RPTR for each ringbuffer even if it is preempted out or if the GPU is turned off
during aggressive power management.
There are risks to
Temporarily disable preemption on a5xx targets pending some improvements
to protect the RPTR shadow from being corrupted.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
This is based on top of Daniel's documentation
patch and it applies cleanly onto amd-staging-drm-next.
I'm also running this live.
Luben Tuikov (1):
drm/amdgpu: Convert to using devm_drm_dev_alloc()
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
1 file changed, 3 insertions(+), 8
Convert to using devm_drm_dev_alloc(),
as drm_dev_init() is going away.
Signed-off-by: Luben Tuikov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
Frank Wunderlich 於 2020年9月3日 週四 下午11:07寫道：
>
> Hi
>
> Any opinion about DTS Patches? Which maintainer will include it in tree? Is
> any ack/review needed?
According to maintainer list [1], the maintainer is
ARM/Mediatek SoC support
M: Matthias Brugger
L: linux-arm-ker...@lists.infradead.org
Add the debugfs nodes needed for the video pattern
compliance tests to MSM DP driver.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_debug.c | 184 ++
drivers/gpu/drm/msm/dp/dp_link.h | 23
2 files changed, 207 insertions(+)
diff --git
No need to fix the number of resolutions to one during the video
pattern CTS test. The userspace test client will handle both
the hotplug as well as picking the right resolution for the test.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dp/dp_display.c | 3 --
To prepare the MSM DP driver for running video pattern
compliance tests introduce debugfs module for it.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/Makefile| 3 +-
drivers/gpu/drm/msm/dp/dp_debug.c | 310
drivers/gpu/drm/msm/dp/dp_debug.h |
Add support for video pattern Display Port Compliance tests to
MSM DP driver. The userspace component of this shall be part of another
series in the igt mailing list.
This depends on series [1] , [2] and [3] which add basic Display Port
support to MSM chipsets.
[1]
Move the MSM DP debugfs node from /sys/kernel/debug/drm_dp
to /sys/kernel/debug/dri/*/ as required for video pattern
compliance test suite.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 7 +
drivers/gpu/drm/msm/dp/dp_debug.c | 31 --
Hi Dave, Daniel,
First batch of new stuff for 5.10. Forgot to mention in the tag, switch
amdgpu from using drm_dev_alloc to drm_dev_init. Will need a follow up
patch to switch to devm_drm_dev_alloc.
The following changes since commit 922e7455bb6122696b0420172700ea2b4e2f5739:
Revert
On Thu, Sep 3, 2020 at 2:11 PM Chia-I Wu wrote:
> On Wed, Sep 2, 2020 at 2:09 PM Gurchetan Singh
> wrote:
> >
> > From: Gerd Hoffmann
> >
> > Implement resource create blob as specified.
> >
> > Signed-off-by: Gerd Hoffmann
> > Co-developed-by: Gurchetan Singh
> > Signed-off-by: Gurchetan
Hi Michael,
Thank you for the patch.
On Thu, Sep 03, 2020 at 06:57:02PM +0200, Michael Tretter wrote:
> 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
On 2020-09-03 21:36, Robin Murphy wrote:
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Signed-off-by: Robin Murphy
---
FYI, get_maintainer.pl
On Wed, Sep 2, 2020 at 2:09 PM Gurchetan Singh
wrote:
>
> From: Gerd Hoffmann
>
> Implement resource create blob as specified.
>
> Signed-off-by: Gerd Hoffmann
> Co-developed-by: Gurchetan Singh
> Signed-off-by: Gurchetan Singh
> Acked-by: Tomeu Vizoso
> ---
>
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Also the DMA segment size is simply a size, not a bitmask.
Signed-off-by: Robin Murphy
---
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Also the DMA segment size is simply a size, not a bitmask.
Signed-off-by: Robin Murphy
---
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Also the DMA segment size is simply a size, not a bitmask.
Signed-off-by: Robin Murphy
---
On 2020-09-03 10:26 a.m., Daniel Vetter wrote:
> 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
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 3 ---
Since commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms
for platform devices"), struct platform_device already provides a
dma_parms structure, so we can save allocating another one.
Signed-off-by: Robin Murphy
---
FYI, get_maintainer.pl seems to be choking on your L: entry
On Thu, 3 Sep 2020 at 18:57, Michael Tretter wrote:
>
> 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
>
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: d57d5c9c09cfb661eb0e8a9c41020aa71771dd7d
commit: e2ef6329fc53a026198a3788db088f85820690b6 [4/5] drm/amdgpu/gmc9: print
client id string for mmhub
config: i386-randconfig-a012-20200902 (attached as .config)
Update the address of Maxime Ripard as one in @free-electrons.com does
not work.
Cc: Maxime Ripard
Signed-off-by: Krzysztof Kozlowski
Acked-by: Maxime Ripard
---
Changes since v1:
1. Add Ack
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.yaml | 2 +-
1 file changed, 1
Device tree nodes should have hyphens instead of underscores. This is
also expected by the bindings.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. New patch
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Device tree nodes should have hyphens instead of underscores. This is
also expected by the bindings.
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. New patch
---
arch/arm/boot/dts/exynos4412.dtsi | 16
arch/arm/boot/dts/exynos5250.dtsi | 2 +-
2 files changed,
Add common properties appearing in DTSes (iommus, power-domains) to fix
dtbs_check warnings like:
arch/arm/boot/dts/exynos4210-i9100.dt.yaml: rotator@1281:
'iommus', 'power-domains' do not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
Changes
Add common properties appearing in DTSes (opp-table) to fix dtbs_check
warnings like:
arch/arm/boot/dts/exynos4210-i9100.dt.yaml: gpu@1300:
'opp-table' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Add properties
Add common properties appearing in DTSes (opp-table) to fix dtbs_check
warnings like:
arch/arm64/boot/dts/exynos/exynos5433-tm2.dt.yaml: gpu@14ac:
'opp-table' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski
---
Changes since v1:
1. Add
On 2020-09-02 9:57 p.m., Pan, Xinhui wrote:
>
>
>> 2020年9月2日 22:50，Tuikov, Luben 写道：
>>
>> On 2020-09-02 00:43, Pan, Xinhui wrote:
>>>
>>>
2020年9月2日 11:46，Tuikov, Luben 写道：
On 2020-09-01 21:42, Pan, Xinhui wrote:
> If you take a look at the below function, you should not use
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
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
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 |
We do not need to keep a reference to the in_bridge_node, but we can
simply drop it, once we found and attached the previous bridge.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git
The probe shall only register the driver at the component framework. The
actual probing happens when the driver is bound.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 27 +
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git
Make the exynos_dsi driver a full drm bridge that can be found and used
from other drivers.
Signed-off-by: Michael Tretter
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 45 +++--
1 file changed, 42 insertions(+), 3 deletions(-)
diff --git
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
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
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
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
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
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.
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
---
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',
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:
> >
> >
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
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: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'
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:
>
(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
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
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'
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
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
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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 /*
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
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
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
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
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
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
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
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
1 - 100 of 154 matches
Mail list logo
