This patch prevents division by zero htotal.
Signed-off-by: Tina Zhang
Cc: Adam Jackson
Cc: Dave Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_modes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index
https://bugs.freedesktop.org/show_bug.cgi?id=109440
Bug ID: 109440
Summary: Radeon RX 580 fails to initialize
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity:
We can't use drmSetMaster to query whether or not a drm fd is master
because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is
DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect
whether or not the fd is
Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.
Changes in v2:
- none
Changes in v3:
- Remove common property definitions (Rob Herring)
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various drivers.
MDSS is one
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Changes in v3:
- Condense multiple lines into a single line (Sean Paul)
Changes in
The interconnect API provides an interface for consumer drivers to express
their bandwidth needs in the SoC. This data is aggregated and the on-chip
interconnect hardware is configured to the appropriate power/performance
profile.
MDSS is one of the interconnect consumers which uses the
Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.
Changes in v2:
- none
Changes in v3:
- Remove common property definitions (Rob Herring)
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Changes in v3:
- Condense multiple lines into a single line (Sean Paul)
Changes in
The interconnect API provides an interface for consumer drivers to express
their bandwidth needs in the SoC. This data is aggregated and the on-chip
interconnect hardware is configured to the appropriate power/performance
profile.
MDSS is one of the interconnect consumers which uses the
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various drivers.
MDSS is one
Hello everyone,
(Thanks to Dan for letting me know my last email got corrupted :/ -
resending it here)
Sincere apologies for chiming in a bit late here, but was off due to some
health issues.
Also, adding Daniel Vetter to the mix, since he has been one of the core
guys who shaped up dma-buf as
https://bugs.freedesktop.org/show_bug.cgi?id=108379
John changed:
What|Removed |Added
CC||john.etted...@gmail.com
--- Comment #5 from
https://bugs.freedesktop.org/show_bug.cgi?id=108854
Tom Seewald changed:
What|Removed |Added
Summary|[polaris11] - Failed GPU|[polaris11] - GPU Hang -
https://bugs.freedesktop.org/show_bug.cgi?id=109359
--- Comment #5 from Timur Kristóf ---
(In reply to keziolio123 from comment #4)
> I have the same issue with an RX480 if i set amdgpu.ppfeaturemask=0x
> (for overclocking), without any command line changes there is no flickering
That's
The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
output when the LVDS0 encoder is used. Enable it despite its output not
being connected.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Add a comment in the DT to explain why the LVDS1 encoder needs to be
enabled.
---
On the D3 and E3 platforms, the LVDS internal PLL supplies the pixel
clock to the DU. This works automatically for LVDS outputs as the LVDS
encoder is enabled through the bridge API, enabling the internal PLL and
clock output. However, when using the DU DPAD output with the LVDS
outputs turned
Hello,
This series adds support for the DPAD0 output for the D3 and E3 SoCs. On
the Draak and Ebisu boards, DPAD0 is used for the VGA output.
Patches 1/6 and 2/6 prepare the grounds by successfully probing LVDS
encoders that have no connected output. This is required in order to
provide a dot
Hi Dave,
A few fixes for v5.0.. the opp-level fix and removal of hard-coded irq
name is partially to make things smoother in v5.1 merge window to
avoid dependency on drm vs dt trees, but are otherwise sane changes.
The following changes since commit ba0ede185ef4c74bfecfe1c992be5dbcc5c5ac04:
The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
output when the LVDS0 encoder is used. Enable it despite its output not
being connected.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Add a comment in the DT to explain why the LVDS1 encoder needs to be
enabled.
---
On the D3 and E3 SoCs the LVDS encoder has an extended internal PLL and
supplies a clock to the DU. That clock is used not only for the LVDS
outputs but also for the DPAD output. The LVDS encoder thus needs to be
available to the DU even when its output is disabled. Don't fail probe
in that case
Before the driver fully moved to drm_bridge and drm_panel, it was
necessary to parse DT and locate encoder and connector nodes. The
connector node is now unused and can be removed as a parameter to
rcar_du_encoder_init(). As a consequence rcar_du_encoders_init_one() can
be greatly simplified,
On the D3 and E3 SoCs the LVDS PLL clock output provides the dot clock
to the DU channels, even when the LVDS outputs are not in use. Enable
and disable the LVDS clock output when enabling or disabling a CRTC
connected to the DPAD0 output.
Signed-off-by: Laurent Pinchart
---
https://bugs.freedesktop.org/show_bug.cgi?id=104362
--- Comment #21 from nmr ---
There may also be a bug in radeonsi, and thanks for the heads up, but every
circumstance where user code causes a kernel hang is a bug.
--
You are receiving this mail because:
You are the assignee for the
On Fri, Jan 18, 2019 at 12:58:10PM -0500, Sean Paul wrote:
> On Wed, Jan 9, 2019 at 1:59 AM Hsin-Yi, Wang wrote:
> >
> > Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
> > to innolux_panel_unprepare(), so they are consistent with
> > innolux_panel_enable() and
https://bugs.freedesktop.org/show_bug.cgi?id=109359
--- Comment #4 from keziolio...@gmail.com ---
I have the same issue with an RX480 if i set amdgpu.ppfeaturemask=0x
(for overclocking), without any command line changes there is no flickering
--
You are receiving this mail because:
You
Hi,
On Mon, Jan 21, 2019 at 9:13 AM Georgi Djakov wrote:
>
> Hi Rob,
>
> On 1/18/19 21:16, Rob Clark wrote:
> > On Fri, Jan 18, 2019 at 1:06 PM Doug Anderson wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Dec 20, 2018 at 9:30 AM Jordan Crouse
> >> wrote:
> >>>
> >>> Try to get the interconnect path
Hi Ronald,
Thank you for the patch.
On Tue, Jan 22, 2019 at 06:13:11AM -0800, Ronald Tschalär wrote:
> commit d6abe6df706c66d803e6dd4fe98c1b6b7f125a56 (drm/bridge:
Commits are usually quoted using the short 12 digits version of their
SHA-1.
> sil_sii8620: do not have a dependency of RC_CORE)
Hi Peter,
Thank you for the patch.
On Fri, Jan 18, 2019 at 11:11:38PM +, Peter Rosin wrote:
> The gpio API explicitly allows skipping the NULL check, precisely to
> allow for neat support for optional gpios. Which is exactly what is at
> play here.
>
> Reported-by: Andrzej Hajda
>
Hi Peter,
Thank you for the patch.
On Sat, Dec 29, 2018 at 07:07:43AM +, Peter Rosin wrote:
> Optionally power down the LVDS-encoder when it is not in use.
>
> Signed-off-by: Peter Rosin
As the powerdown-gpios property is only defined for two encoders, and
both of them should work well
On Tue, Jan 22, 2019 at 4:19 AM Ard Biesheuvel
wrote:
>
> On Mon, 21 Jan 2019 at 20:04, Michel Dänzer wrote:
> >
> > On 2019-01-21 7:28 p.m., Ard Biesheuvel wrote:
> > > On Mon, 21 Jan 2019 at 19:24, Michel Dänzer wrote:
> > >> On 2019-01-21 7:20 p.m., Ard Biesheuvel wrote:
> > >>> On Mon, 21
Hi Peter,
Thank you for the patch.
On Sat, Dec 29, 2018 at 07:07:37AM +, Peter Rosin wrote:
> Make the code easier to read and modify.
>
> Signed-off-by: Peter Rosin
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/bridge/lvds-encoder.c | 19 +--
> 1 file changed,
Hi Peter,
Thank you for the patch.
On Sat, Dec 29, 2018 at 07:07:31AM +, Peter Rosin wrote:
> The name powerdown-gpios is the standard property name for the
> functionality covered by the previous pwdn-gpios name. This rename
> should be safe to do since the linux driver supporting the
Hello,
On Fri, Jan 11, 2019 at 08:49:04AM -0600, Rob Herring wrote:
> On Sat, Dec 29, 2018 at 07:07:19AM +, Peter Rosin wrote:
> > DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
> > binding, which is meant to be generic.
> >
> > The sister chip DS90C187 is similar to
Hi Peter,
Thank you for the patch.
On Sat, Dec 29, 2018 at 07:07:25AM +, Peter Rosin wrote:
> Drop #address-cells and #size-cells from the root node in the
> example, they are unused.
>
> Reviewed-by: Rob Herring
> Signed-off-by: Peter Rosin
Reviewed-by: Laurent Pinchart
> ---
>
Hi Geert,
On Thu, Jan 17, 2019 at 11:21:32AM +0100, Geert Uytterhoeven wrote:
> On Thu, Jan 17, 2019 at 3:07 AM Laurent Pinchart
> wrote:
> > The LVDS1 encoder must supply a pixel clock to the DU for the DPAD
> > output when the LVDS0 encoder is used. Enable it despite its output not
> > being
Hi Nathan,
Thank you for the patch.
On Fri, Jan 18, 2019 at 10:21:25AM -0700, Nathan Chancellor wrote:
> On arm{32,64} allyesconfig builds:
>
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c:40:1: error: incomplete result type
> 'enum drm_mode_status' in function definition
>
On Mon, Dec 17, 2018 at 03:34:09PM -0800, Tanmay Shah wrote:
> Correct definition of both formats by swapping red
> and blue channels
>
> v3: update commit message
>
> Signed-off-by: Tanmay Shah
Applied to dpu-staging, thanks!
Sean
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++--
On Tue, Dec 18, 2018 at 05:05:48PM +0530, Jayant Shekhar wrote:
> Remove unused functions and macros from files handling
> dpu hardware interrupts.
>
> changes in v2:
> Removed clear_interrupt_status (Jordan Crouse)
> changes in v3:
> Changed commit text
>
> Signed-off-by: Jayant Shekhar
On Tue, Dec 18, 2018 at 06:50:38PM +0530, Jayant Shekhar wrote:
> Remove unused functions from dpu plane interface
> and unused variables from dpu plane state structure.
>
> Signed-off-by: Jayant Shekhar
Applied to dpu-staging, thanks!
Sean
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |
On Wed, Dec 19, 2018 at 12:23:53AM +0530, Jayant Shekhar wrote:
> Remove enum dpu_iommu_domain from dpu mdss as its unused.
>
> Remove unnecessary comment for variable which is already
> removed.
>
> Signed-off-by: Jayant Shekhar
Applied to dpu-staging, thanks!
Sean
> ---
>
From: Ville Syrjälä
Make the code a bit easier to read by providing symbolic names
for the reply_type (ACK vs. NAK). Also clean up some brace stuff
while at it.
v2: s/DP_REPLY/DP_SIDEBAND_REPLY/ (DK)
Fix some checkpatch issues
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
From: Ville Syrjälä
Decode the NAK reply fields to make it easier to parse the logs.
v2: s/STR/DP_STR/ to avoid conflict with some header stuff (0day)
Use drm_dp_mst_req_type_str() more (DK)
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
---
On Tue, Jan 22, 2019 at 07:42:30PM +, Wentland, Harry wrote:
>
>
> On 2019-01-22 2:19 p.m., Daniel Vetter wrote:
> > On Tue, Jan 22, 2019 at 8:00 PM Wentland, Harry
> > wrote:
> >> On 2019-01-16 11:39 a.m., Daniel Vetter wrote:
> >>> Compared to the RFC[1] no changes to the patch itself,
https://bugs.freedesktop.org/show_bug.cgi?id=104362
--- Comment #20 from Axel Davy ---
It looks like from the previous comments the problem is in radeonsi.
As a 'temporary fix', you could try this patch:
https://github.com/iXit/Mesa-3D/commit/976f3fe791b0aa34cc04eaac53147eb60089e0f7
This patch
On 2019-01-22 2:19 p.m., Daniel Vetter wrote:
> On Tue, Jan 22, 2019 at 8:00 PM Wentland, Harry
> wrote:
>> On 2019-01-16 11:39 a.m., Daniel Vetter wrote:
>>> Compared to the RFC[1] no changes to the patch itself, but igt moved
>>> forward a lot:
>>>
>>> - gitlab CI builds with: reduced
On Mon, Dec 17, 2018 at 02:35:04PM -0800, Jeykumar Sankaran wrote:
> Bail out KMS hw init on display initialization failures with
> proper error logging.
>
> changes in v3:
> - introduced in the series
> changes in v4:
> - avoid duplicate return on errors (Sean Paul)
> - avoid
On Tue, Jan 22, 2019 at 8:07 PM Noralf Trønnes wrote:
>
>
>
> Den 22.01.2019 10.32, skrev Daniel Vetter:
> > On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 21.01.2019 10.55, skrev Daniel Vetter:
> >>> On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter
On Mon, Dec 17, 2018 at 02:35:03PM -0800, Jeykumar Sankaran wrote:
> Fix intf_type description in msm_disp_info to show that
> it represents drm encoder mode of the display.
>
> changes in v3:
> - introduced in the series
> changes in v4:
> - none
>
> Signed-off-by: Jeykumar Sankaran
On Tue, Jan 22, 2019 at 8:00 PM Wentland, Harry wrote:
> On 2019-01-16 11:39 a.m., Daniel Vetter wrote:
> > Compared to the RFC[1] no changes to the patch itself, but igt moved
> > forward a lot:
> >
> > - gitlab CI builds with: reduced configs/libraries, arm cross build
> > and a sysroot build
On Mon, Jan 21, 2019 at 07:03:49AM +0100, Lubomir Rintel wrote:
> Heavily based on the Armada 510 (Dove) support. Like with 510 support, this
> also just supports a single source clock -- the "Display 1" clock as
> generated by the APMU. This one was chosen because the OLPC XO 1.75 laptop
> uses
Den 22.01.2019 10.32, skrev Daniel Vetter:
> On Mon, Jan 21, 2019 at 01:21:46PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 21.01.2019 10.55, skrev Daniel Vetter:
>>> On Mon, Jan 21, 2019 at 10:10:14AM +0100, Daniel Vetter wrote:
On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes wrote:
On Mon, Jan 21, 2019 at 07:01:57AM +0100, Lubomir Rintel wrote:
> If there's a simple-framebuffer carried over from boot firmware, it's going
> to stop working once we setup the LCDC for use via DRM. Kick it off from
> the hardware.
Applied, thanks.
>
> Signed-off-by: Lubomir Rintel
> ---
>
On Thu, Jan 03, 2019 at 11:06:02AM -0800, Stephen Boyd wrote:
> Devices that make up DPU, i.e. graphics card, request their interrupts
> from this "virtual" interrupt chip. The interrupt chip builds upon a GIC
> SPI interrupt that raises high when any of the interrupts in the DPU's
> irq status
On 2019-01-16 11:39 a.m., Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
> concerns raised
On Tue, Jan 22, 2019 at 07:22:24PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To make vblank timestamps work better with the TV encoder let's
> > scale the pipe timings such that the relationship between the
> > TV
Hello everyone,
Sincere apologies for chiming in a bit late here, but was off due to
some health issues.
Also, adding Daniel Vetter to the mix, since he has been one of the
core guys who shaped up dma-buf as it is today.
On Tue, 22 Jan 2019 at 02:51, Andrew F. Davis wrote:
On 1/21/19 5:22
On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make vblank timestamps work better with the TV encoder let's
> scale the pipe timings such that the relationship between the
> TV active and TV blanking periods is mirrored in the
> corresponding pipe
Hi Biju,
Thank you for the patch.
On Tue, Jan 22, 2019 at 03:25:48PM +, Biju Das wrote:
> Add du node to r8a7744 SoC DT. Boards that want to enable the DU
> need to specify the output topology.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
I expect Simon to pick this up.
>
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #30 from quirin.blae...@freenet.de ---
Bug is still alive. amd-staging-drm-next
d2d07f246b126b23d02af0603b83866a3c3e2483
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> According to our IOMMU folks there exists some desire to be able to assign
> the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> due to how the devices might be grouped in IOMMU groups. Even when you
> would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Alex Deucher (1):
amdgpu: update to latest marketing names from 18.50
Andrey Grodzovsky (3):
amdgpu/test: Add illegal register and memory access test v2
amdgpu/test: Disable deadlock tests for all non gfx8/9 ASICs.
https://bugs.freedesktop.org/show_bug.cgi?id=108037
--- Comment #11 from Öyvind Saether ---
Created attachment 143199
--> https://bugs.freedesktop.org/attachment.cgi?id=143199=edit
This is still a problem with kernel 4.20.3, happens sometime when turning
multiple monitors on at the same time
On Tue, Jan 22, 2019 at 5:11 PM Sean Paul wrote:
> On Tue, Jan 22, 2019 at 04:17:25PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 22, 2019 at 4:08 PM Brian Starkey wrote:
> > >
> > > On Tue, Jan 22, 2019 at 03:03:59PM +0100, Daniel Vetter wrote:
> > > > On Tue, Jan 22, 2019 at 2:27 PM Brian
On Tue, Jan 22, 2019 at 04:17:25PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2019 at 4:08 PM Brian Starkey wrote:
> >
> > On Tue, Jan 22, 2019 at 03:03:59PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 22, 2019 at 2:27 PM Brian Starkey
> > > wrote:
> >
/snip
>
> > > > > > > That seems a
On 1/21/19 4:12 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>
>> On Mon, Jan 21, 2019 at 11:44:10AM -0800, Liam Mark wrote:
>>> The main use case is for allowing clients to pass in
>>> DMA_ATTR_SKIP_CPU_SYNC in order to skip the default cache maintenance
>>> which
On Tue, Jan 22, 2019 at 4:58 AM Russell King - ARM Linux admin
wrote:
>
> On Mon, Jan 21, 2019 at 05:58:50PM -0600, Rob Herring wrote:
> > On Mon, Jan 21, 2019 at 11:53 AM Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> > > >
Hi Biju,
Thank you for the patch.
On Tue, Jan 22, 2019 at 03:25:47PM +, Biju Das wrote:
> The LVDS encoders on RZ/G1N SoC is similar to RZ/G1M. Add support for
> RZ/G1N (R8A7744) SoC to the LVDS encoder driver.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
and taken in my
Hi Biju,
Thank you for the patch.
On Tue, Jan 22, 2019 at 03:25:46PM +, Biju Das wrote:
> Document the RZ/G1N (R8A7744) LVDS bindings.
>
> Signed-off-by: Biju Das
Reviewed-by: Laurent Pinchart
and taken in my tree.
> ---
>
On 1/21/19 4:18 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/21/19 2:20 PM, Liam Mark wrote:
>>> On Mon, 21 Jan 2019, Andrew F. Davis wrote:
>>>
On 1/21/19 1:44 PM, Liam Mark wrote:
> On Mon, 21 Jan 2019, Christoph Hellwig wrote:
>
>> On Sat, Jan
There is no need to keep the dentries around for the individual debugfs
files, just delete the whole directory all at once at shutdown instead.
This also fixes a tiny memory leak where the memory for the pointers to
the file dentries was never freed when the device shut down, as well as
making
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Bartlomiej Zolnierkiewicz
Cc: Mauro Carvalho Chehab
Cc: linux-o...@vger.kernel.org
Cc:
On Tue, Jan 22, 2019 at 4:08 PM Brian Starkey wrote:
>
> On Tue, Jan 22, 2019 at 03:03:59PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 22, 2019 at 2:27 PM Brian Starkey wrote:
>
> [snip]
>
> > >
> > > That doesn't really address my issue, but no matter. I guess I'm
> > > having a hard time
On Mon, Nov 12, 2018 at 06:59:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the missing 1080p TV modes. On gen4 all of them work just fine,
> whereas on gen3 only the 30Hz mode actually works correctly.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
On Tue, Jan 22, 2019 at 03:03:59PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2019 at 2:27 PM Brian Starkey wrote:
[snip]
> >
> > That doesn't really address my issue, but no matter. I guess I'm
> > having a hard time separating the existing igts from _new_ igts for
> > new features; so
On Mon, Nov 12, 2018 at 06:59:56PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the silly reported_modes[] array. I suppse once upon a time
> this actually had something to do with modes we reported to userspace.
> Now it is just the placeholder for the mode we use for load
On Mon, Nov 12, 2018 at 06:59:55PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current code insists on picking a new TV mode when
> switching between component and non-component cables.
> That's super annoying. Let's just keep the current TV
> mode unless the new cable type
Quoting Joerg Roedel (2019-01-22 13:01:09)
> Hi Daniel,
>
> On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> > Note that the string of platforms which have various issues with iommu
> > and igfx is very long, thus far we only disabled it where there's no
> > workaround to stop it
On Mon, Nov 12, 2018 at 06:59:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No point in storing the mode names in the array. drm_mode_set_name()
> will give us the same names without wasting space for these string
> constants.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre
On Mon, Nov 12, 2018 at 06:59:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rewrite the preferred mode selection to just check
> whether the TV modes is HD or SD. For SD TV modes we
> favor 480 line modes, for 720p we prefer 720 line modes,
> and for 1080i/p we prefer 1080 line
From: Thierry Reding
Tegra186 and later use the ARM SMMU driver to provide IOMMU domains. The
driver sets the IOMMU domain's geometry only after a device has attached
to the domain. However, in order to properly set up the IOMMU domain
shared among all Tegra DRM clients, the domain's geometry is
On Tue, Jan 22, 2019 at 2:27 PM Brian Starkey wrote:
>
> Hi,
>
> On Tue, Jan 22, 2019 at 09:53:20AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 21, 2019 at 6:21 PM Daniel Vetter
> > wrote:
> > >
> > > On Mon, Jan 21, 2019 at 12:54 PM Brian Starkey
> > > wrote:
> > > >
> > > > Hi Daniel,
> > >
Hi,
On Tue, Jan 22, 2019 at 09:53:20AM +0100, Daniel Vetter wrote:
> On Mon, Jan 21, 2019 at 6:21 PM Daniel Vetter wrote:
> >
> > On Mon, Jan 21, 2019 at 12:54 PM Brian Starkey
> > wrote:
> > >
> > > Hi Daniel,
> > >
> > > On Thu, Jan 17, 2019 at 12:52:16PM +0100, Daniel Vetter wrote:
> > > >
On Mon, Nov 12, 2018 at 06:59:51PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Just assign the margin values directly to xpos/ypos instead
> of first initializing to zero and then adding the values.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
>
On Mon, Nov 12, 2018 at 06:59:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 'component_only' is a bool. Initialize it like a bool.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 24
> 1 file changed,
On Mon, Nov 12, 2018 at 06:59:49PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the oversampling factor as a number in the TV modes. We
> shall want to arithmetic with this which is easier if it's
> a number we can use directly.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by:
On Mon, Nov 12, 2018 at 06:59:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The oversample clock is always supposed to be either 108 MHz
> or 148.5 MHz. Make it so.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
> ---
>
On Mon, Nov 12, 2018 at 06:59:47PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fix the calculation of the vertical active period for interlaced
> TV modes.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 2 +-
>
On Tue, Nov 27, 2018 at 10:05:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On i965gm the hardware frame counter does not work when
> the TV encoder is active. So let's not try to consult
> the hardware frame counter in that case. Instead we'll
> fall back to the timestamp based
On Tue, Jan 22, 2019 at 4:41 PM Maxime Ripard wrote:
>
> On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote:
> > On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki
> > wrote:
> > >
> > > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard
> > > wrote:
> > > >
> > > > On Sun, Jan 13, 2019 at
On Thu, Jan 17, 2019 at 10:02:12AM +0530, Jagan Teki wrote:
> On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard
> wrote:
> >
> > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > > > > > Again, I cannot help you without the datasheet for the panels
> > > > > > > > you're
> > > > >
From: "james qian wang (Arm Technology China)"
CHIP set bus_width according to the HW configuration, and CORE will use
it as buffer alignment.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 1 +
From: "james qian wang (Arm Technology China)"
Add two sysfs node: core_id, config_id, user can read them to fetch the
HW product information.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_product.h | 12 +
From: "james qian wang (Arm Technology China)"
Add a new komeda_dev_func->on_off_vblank to enable/disable HW vblank event
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 10 ++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 19
On Fri, Jan 18, 2019 at 09:14:19PM +0530, Jagan Teki wrote:
> On Thu, Jan 17, 2019 at 10:02 AM Jagan Teki
> wrote:
> >
> > On Thu, Jan 17, 2019 at 12:48 AM Maxime Ripard
> > wrote:
> > >
> > > On Sun, Jan 13, 2019 at 01:07:41AM +0530, Jagan Teki wrote:
> > > > > > > > > Again, I cannot help you
From: "james qian wang (Arm Technology China)"
Pass enable/disable command to komeda and adjust komeda hardware for
enable/disable a display instance.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 106 +-
From: "james qian wang (Arm Technology China)"
Added functions:
- komeda_crtc_reset
- komeda_crtc_vblank_enable
- komeda_crtc_vblank_disable
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 48 +++
1 file changed, 48
From: "james qian wang (Arm Technology China)"
These two function will be used by komeda_crtc_enable/disable to do some
prepartion works when enable/disable a crtc. like enable a crtc:
1. Adjust display operation mode.
2. Enable/prepare needed clk.
v2: Rebase
Signed-off-by: James Qian Wang
From: "james qian wang (Arm Technology China)"
Implement komeda_kms_check to add all affected_planes (even unchanged) to
drm_atomic_state. since komeda need to re-calculate the resources
assumption in every commit.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
From: "james qian wang (Arm Technology China)"
komeda_crtc_mode_valid compares the input mode->clk with main engine clk
and AXI clk, and reject the mode if the required pixel clk can not be
satisfied by main engine clk and AXI-clk.
Signed-off-by: James Qian Wang (Arm Technology China)
---
1 - 100 of 176 matches
Mail list logo
