On Mon, Jan 21, 2019 at 11:13 PM Sam Ravnborg wrote:
>
> Hi Daniel et al.
>
> > >
> > > Yeah the drm_crtc_helper.h header is a bit the miniature drmP.h for legacy
> > > kms drivers. Just removing it from all the atomic drivers caused lots of
> > > fallout, I expect even more if you entirely remove
Hi Laurent,
On Tue, Jan 22, 2019 at 4:07 AM Laurent Pinchart
wrote:
> On Mon, Jan 21, 2019 at 11:18:26AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 21, 2019 at 11:03:44AM +0100, Geert Uytterhoeven wrote:
> > > On Mon, Jan 21, 2019 at 10:35 AM Daniel Vetter wrote:
> > >> On Fri, Jan 18, 2019 at
On Mon, 21 Jan 2019, Ville Syrjälä wrote:
> On Mon, Jan 21, 2019 at 01:27:58PM +0200, Jani Nikula wrote:
>> We have a wrapper for a reason.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Thanks, pushed to drm-misc-next.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/drm_dp_helper.c
Am 22.01.19 um 00:20 schrieb Chris Wilson:
> Rather than every backend and GPU driver reinventing the same wheel for
> user level debugging of HW execution, the common dma-fence framework
> should include the tracing infrastructure required for most client API
> level flow visualisation.
>
> With t
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 Thu, Jan 17, 2019 at 12:38 PM Liviu Dudau wrote:
> > > >
> > > > On Wed, Jan 16, 2019
Use the mtk_pwm_data struction to define different registers
and add MT8183 specific register operations, such as MT8183
doesn't have commit register, needs to disable double buffer
before writing register, and needs to select commit mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Jitao Shi
Use the mtk_pwm_data struction to define different registers
and add MT8183 specific register operations, such as MT8183
doesn't have commit register, needs to disable double buffer
before writing register, and needs to select commit mode
and use PWM_PERIOD/PWM_HIGH_WIDTH.
Signed-off-by: Jitao Shi
Quoting Koenig, Christian (2019-01-22 08:49:30)
> Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > Rather than every backend and GPU driver reinventing the same wheel for
> > user level debugging of HW execution, the common dma-fence framework
> > should include the tracing infrastructure required fo
https://bugs.freedesktop.org/show_bug.cgi?id=108317
--- Comment #20 from Dimitar Atanasov ---
I have same problem with kernel 5.0 rc2 and Mesa 19git 7bef192 (trough Padoka
PPA), picture is OK if you use R600_DEBUG=nohyperz. For me it is around 10 FPS
less with this option set in some games. VegaM
On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson wrote:
>
> Quoting Koenig, Christian (2019-01-22 08:49:30)
> > Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > > Rather than every backend and GPU driver reinventing the same wheel for
> > > user level debugging of HW execution, the common dma-fence fra
On Tue, Jan 22, 2019 at 05:02:43PM +0800, Jitao Shi wrote:
> Use the mtk_pwm_data struction to define different registers
> and add MT8183 specific register operations, such as MT8183
> doesn't have commit register, needs to disable double buffer
> before writing register, and needs to select commi
On Tue, Jan 22, 2019 at 09:32:32AM +0200, Priit Laes wrote:
> From: Priit Laes
>
> Although TMDS clock is required for HDMI to properly function,
> nobody called clk_prepare_enable(). This fixes reference counting
> issues and makes sure clock is running when it needs to be running.
>
> Due to T
On 1/18/19 1:43 PM, Julien Grall wrote:
> (+ Stefano)
>
> Hi,
>
> Sorry for jumping late in the conversation.
>
> On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
>> On 1/17/19 11:18 AM, Christoph Hellwig wrote:
>>> On Wed, Jan 16, 2019 at 06:43:29AM +, Oleksandr Andrushchenko
>>> wrote:
>>
On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>
> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
> >
> >> Until that happens we should just change the driver ifdefs to default
> >> the hacks to off and only enable them on setups wher
On Mon, Jan 21, 2019 at 08:37:29AM +, Priit Laes wrote:
> On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote:
> > Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a):
> > > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote:
> > > > Dne sreda, 16. janua
On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote:
>
> > +#include
>
> This header is not for usage in device drivers, but purely for
> dma-mapping implementations!
>
Is that documented anywhere?
> > +static inline bool drm_device_can_wc_memory(struct drm_device *ddev)
> > {
> > + if (
Currently, the DRM code assumes that PCI devices are always cache
coherent for DMA, and that this can be selectively overridden for
some buffers using non-cached mappings on the CPU side and PCIe
NoSnoop transactions on the bus side.
Whether the NoSnoop part is implemented correctly is highly plat
On Mon, 2019-01-21 at 17:53 +, Russell King - ARM Linux admin
wrote:
> On Mon, Jan 21, 2019 at 10:07:11AM -0600, Rob Herring wrote:
> > On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
> > > On Mon, 2019-01-21 at 09:35 -0600, Rob Herring wrote:
> > > > On Sun, Jan 20, 2019 at 11:26 AM Lub
On Mon, 21 Jan 2019 at 17:35, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 05:30:00PM +0100, Ard Biesheuvel wrote:
> > > Until that happens we should just change the driver ifdefs to default
> > > the hacks to off and only enable them on setups where we 100%
> > > positively know that they
On 1/21/19 7:17 AM, Vincent Guittot wrote:
On Fri, 18 Jan 2019 at 13:08, Guenter Roeck wrote:
On 1/18/19 3:05 AM, Rafael J. Wysocki wrote:
On Fri, Jan 18, 2019 at 11:53 AM Vincent Guittot
wrote:
On Fri, 18 Jan 2019 at 11:42, Vincent Guittot
wrote:
Hi Guenter,
Le Thursday 17 Jan 2019 à
On Mon, 21 Jan 2019 at 16:59, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 04:33:27PM +0100, Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 16:07, Christoph Hellwig wrote:
> > >
> > > > +#include
> > >
> > > This header is not for usage in device drivers, but purely for
> > > dma-mappi
On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> On 1/17/19 7:11 PM, Liam Mark wrote:
> > On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/16/19 4:54 PM, Liam Mark wrote:
> >>> On Wed, 16 Jan 2019, Andrew F. Davis wrote:
> >>>
> On 1/16/19 9:19 AM, Brian Starkey wrote:
> > Hi :-)
>
Dne ponedeljek, 21. januar 2019 ob 14:34:33 CET je Priit Laes napisal(a):
> On Mon, Jan 21, 2019 at 08:37:29AM +, Priit Laes wrote:
> > On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote:
> > > Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a):
> > > > On Wed, Ja
Hello,
On 21/01/2019 12:43, Oleksandr Andrushchenko wrote:
On 1/18/19 1:43 PM, Julien Grall wrote:
On 18/01/2019 09:40, Oleksandr Andrushchenko wrote:
On 1/17/19 11:18 AM, Christoph Hellwig wrote:
On Wed, Jan 16, 2019 at 06:43:29AM +, Oleksandr Andrushchenko
wrote:
This whole issue keeps
On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig wrote:
>
> On Mon, Jan 21, 2019 at 05:14:37PM +0100, Ard Biesheuvel wrote:
> > > I'll add big fat comments. But the fact that nothing is exported
> > > there should be a fairly big hint.
> > >
> >
> > I don't follow. How do other header files 'expor
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Mon, Jan 21, 2019 at 12:20:42PM -0800, Liam Mark wrote:
> > I have left this to clients, but if they own the buffer they can have the
> > knowledge as to whether CPU access is needed in that use case (example for
> > post-processing).
>
> That
From: Priit Laes
Although TMDS clock is required for HDMI to properly function,
nobody called clk_prepare_enable(). This fixes reference counting
issues and makes sure clock is running when it needs to be running.
Due to TDMS clock being parent clock for DDC clock, TDMS clock
was turned on/off f
Dne ponedeljek, 21. januar 2019 ob 16:07:28 CET je Priit Laes napisal(a):
> On Mon, Jan 21, 2019 at 02:25:17PM +0100, Maxime Ripard wrote:
> > On Fri, Jan 18, 2019 at 02:51:26PM +, Priit Laes wrote:
> > > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote:
> > > > On Fri, Jan 18, 201
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 Jan 2019 at 19:04, Michel Dänzer wrote:
> >>
> >> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
>
> On 2019-01-
On Mon, 21 Jan 2019, Andrew F. Davis wrote:
> On 1/18/19 3:43 PM, Liam Mark wrote:
> > On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/17/19 7:04 PM, Liam Mark wrote:
> >>> On Thu, 17 Jan 2019, Andrew F. Davis wrote:
> >>>
> On 1/16/19 4:48 PM, Liam Mark wrote:
> > On Wed, 16 J
On Mon, 21 Jan 2019, Christoph Hellwig wrote:
> On Sat, Jan 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
> > > And who is going to decide which ones to pass? And who documents
> > > which ones are safe?
> > >
> > > I'd much rather have explicit, well documented dma-buf flags that
> > > migh
Clang warns:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_crat.c:866:5: warning:
'CONFIG_X86_64' is not defined, evaluates to 0 [-Wundef]
#if CONFIG_X86_64
^
1 warning generated.
Fixes: d1c234e2cd10 ("drm/amdkfd: Allow building KFD on ARM64 (v2)")
Signed-off-by: Nathan Chancellor
---
Resending
On Mon, 2019-01-21 at 09:35 -0600, Rob Herring wrote:
> On Sun, Jan 20, 2019 at 11:26 AM Lubomir Rintel wrote:
> > The Marvell Armada DRM master device is a virtual device needed to list all
> > nodes that comprise the graphics subsystem.
> >
> > Signed-off-by: Lubomir Rintel
> > ---
> > .../di
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 Jan 2019 at 19:04, Michel Dänzer wrote:
> On 2019-01-21 6:59 p.m.
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 Jan 2019 at 19:04, Michel Dänzer wrote:
> On 2019-01-21 6:59 p.m.
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 19, 2019 at 08:50:41AM -0800, Laura Abbott
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 for the GPU and vote for the maximum
>>> bandwidth to support all frequencies. This is n
On Fri, Jan 11, 2019 at 8:33 PM Souptick Joarder wrote:
>
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized b
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 happens in dma_buf_map_attachment and dma_buf_un
On Mon, 21 Jan 2019 at 19:04, Michel Dänzer wrote:
>
> On 2019-01-21 6:59 p.m., Ard Biesheuvel wrote:
> > On Mon, 21 Jan 2019 at 18:55, Michel Dänzer wrote:
> >>
> >> On 2019-01-21 5:30 p.m., Ard Biesheuvel wrote:
> >>> On Mon, 21 Jan 2019 at 17:22, Christoph Hellwig
> >>> wrote:
> >>>
> U
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 19, 2019 at 08:50:41AM -0800, Laura Abbott wrote:
> And who is going to decide which ones to pass? And who documents
> which ones ar
On Mon, Jan 21, 2019 at 02:25:17PM +0100, Maxime Ripard wrote:
> On Fri, Jan 18, 2019 at 02:51:26PM +, Priit Laes wrote:
> > On Fri, Jan 18, 2019 at 03:04:18PM +0100, Maxime Ripard wrote:
> > > On Fri, Jan 18, 2019 at 10:10:53AM +, Priit Laes wrote:
> > > > > > > > > It doesn't look related
On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote:
> The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
> /dev/nvram misc device. This module is used only by 32-bit PowerPC
> platforms.
>
> The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a
> /dev/nvr
From: "james qian wang (Arm Technology China)"
1. Add detailed layer/layer_state definitions
2. Add d71_layer_init to report layer features and capabilities according
to D71 layer block.
3. Add d71_layer_updat/disable
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China)
---
..
From: "james qian wang (Arm Technology China)"
Add and initialize improc and timing_ctrlr according to D71 capablitites
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 111 +-
.../gpu/drm/arm/display/komeda/
From: "james qian wang (Arm Technology China)"
D71 consists of a number of Register Blocks, every Block controls a
specific HW function, every block has a common block_header to represent
its type and pipeline information.
GCU (Global Control Unit) is the first Block which describe the global
in
This is the 2nd patchset for komeda-driver.
These patches focus on CHIP(D71) Layer for pipeline/component descovery and
initialization. All basic and essential display component: layer, compiz,
improc, timing-ctrlr and irq handling have been added, other component
support: scaler, wb_layer, merger
From: "james qian wang (Arm Technology China)"
Implement d71_compiz_init and add compiz component to komeda-CORE
v2: Rebase.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 92 ++-
.../drm/arm/display/komeda/komeda_pipe
From: "james qian wang (Arm Technology China)"
komeda_accemble_pipelines is for:
1. Verifing the component->supported_inputs according to the
pipeline->avail_components.
2. Generating component->supported_outputs.
v2: Lower the debug message of komeda_component_dump to DRM_DEBUG.
Signed-off
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:
> >>> This adds resource managed (devres) versio
On Sun, Jan 20, 2019 at 12:43:08PM +0100, Noralf Trønnes wrote:
> This adds resource managed (devres) versions of drm_dev_init() and
> drm_dev_register().
>
> Also added is devm_drm_dev_register_with_fbdev() which sets up generic
> fbdev emulation as well.
>
> devm_drm_dev_register() isn't export
On Tue, 2019-01-22 at 10:16 +0100, Uwe Kleine-König wrote:
> On Tue, Jan 22, 2019 at 05:02:43PM +0800, Jitao Shi wrote:
> > Use the mtk_pwm_data struction to define different registers
> > and add MT8183 specific register operations, such as MT8183
> > doesn't have commit register, needs to disable
On Mon, Jan 21, 2019 at 10:24:28PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Only some of the drm mode object lookups have a corresponding debug
> print for the lookup failure. That makes logs a bit hard to parse
> when you can't see where the bad object ID is being used. Add a bunch
From: "james qian wang (Arm Technology China)"
Add a debugfs node "register" and entry function dump_register to
dev/pipeline/component to register dump, then user can read
"/sys/kernel/debug/komeda/register" to get the register values via these
chip function.
Signed-off-by: James Qian Wang (Arm
https://bugzilla.kernel.org/show_bug.cgi?id=199115
Hans de Goede (jwrdego...@fedoraproject.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Mon, Jan 21, 2019 at 10:24:29PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Use ENOENT consistently for the case where the requested property
> isn't found, and EINVAL for the case where the object has no
> properties whatsoever. Currenrly these are handled differently
> in the atomi
From: "james qian wang (Arm Technology China)"
1. Added irq_handler/irq_enable/irq_disable to komeda_dev_func, then the
Komeda-CORE can control the HW irq via these chip function.
2. Install irq and register irq_handler to system by DRM, so once the IRQ
coming, the handling sequence is:
On Mon, Jan 21, 2019 at 10:24:30PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Logs can get confusing when some operations are done multiple times
> due to the ww mutex backoff. Add a debug print into
> drm_modeset_backoff() so that at least the reason for the odd
> looking logs will be
Quoting Daniel Vetter (2019-01-22 09:11:53)
> On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson
> wrote:
> >
> > Quoting Koenig, Christian (2019-01-22 08:49:30)
> > > Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > > > Rather than every backend and GPU driver reinventing the same wheel for
> > > > use
On Mon, Jan 21, 2019 at 04:59:52PM +0300, Dan Carpenter wrote:
> The mdev->irq value comes from platform_get_irq() so it can't be more
> than INT_MAX and if it's unsigned then it breaks the error handling in
> komeda_parse_dt().
>
> Fixes: 29e56aec911d ("drm/komeda: Add DT parsing")
> Signed-off-by
On Tue, Jan 22, 2019 at 10:58 AM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2019-01-22 09:11:53)
> > On Tue, Jan 22, 2019 at 10:06 AM Chris Wilson
> > wrote:
> > >
> > > Quoting Koenig, Christian (2019-01-22 08:49:30)
> > > > Am 22.01.19 um 00:20 schrieb Chris Wilson:
> > > > > Rather than e
Hi,
On Fri, 2019-01-18 at 19:20 +0100, Maxime Ripard wrote:
> On Fri, Jan 18, 2019 at 03:51:10PM +0100, Paul Kocialkowski wrote:
> > This series implements support for YUV formats using the display engine
> > frontend in the sun4i DRM driver, with various fixes along the way.
> > Scaling is suppor
On Tue, Jan 22, 2019 at 11:39 AM Joerg Roedel wrote:
>
> On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> > @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> > quirk_iommu_g4x_gfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_
On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, q
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:
> > > On Mon, Jan 21, 2019 at 9:46 AM Lubomir Rintel wrote:
> > > >
> > > > On Mon, 2019-01-
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 from hanging the box, but otherwise left it
> enabled. S
This is the 3rd patchset for the komeda driver.
This patchset implemented plane/plane_helper functions for DRM-Plane.
per the komeda driver design, A DRM-plane maps to komeda layer input
pipeline, so the plane->atomic_check will build a layer input pipeline
according to the plane_state. and with t
From: "james qian wang (Arm Technology China)"
This pair of functions return the old/new private object state for the
given private_obj, or NULL if the private_obj is not part of the global
atomic state.
Reviewed-by: Alexandru Gheorghe
Signed-off-by: James Qian Wang (Arm Technology China)
---
From: "james qian wang (Arm Technology China)"
get_state_and_set_user packed get_state and set_user into one function,
which get pipeline/component state for a specific pipeline/component, if
success set the user to it.
v2:
- Rebase.
- Applied commit:
b962a12050a3 ("drm/atomic: integrate modes
From: "james qian wang (Arm Technology China)"
Initialize koemda_layer, komeda_compiz, komeda_improc and
komeda_timing_ctrlr as drm private object, then track komeda private
component state by drm_atomic_state.
v2:
- Update code after Applied commit:
b962a12050a3 ("drm/atomic: integrate modese
From: "james qian wang (Arm Technology China)"
Per komeda design KMS-plane maps to komeda layer input pipeline.
komeda_plane_atomic_check is for building a komeda layer input pipeline.
And KMS-plane is only a user of komeda resources. so there is no real HW
update for plane, but all HW update wi
From: "james qian wang (Arm Technology China)"
build_layer_data_flow builds a input pipeline according to plane_state.
and in this initial stage only added this simplest pipeline usage:
Layer -> compiz
The scaler and layer_split will be added in the future.
v2:
- Rebase.
- Introduce struct kom
This is the 4th patchset for komeda-driver, with this patchset the driver
can bring up and enable the D71 support with basic features.
This patchset implemented komeda_crtc/crtc_helper functions for
DRM-crtc.
v2: Rebase
james qian wang (Arm Technology China) (11):
drm/komeda: Add komeda_build_
From: "james qian wang (Arm Technology China)"
Komeda driver treats KMS-CRTC/PLANE as user which will acquire pipeline
resources, but we still need to release the unclaimed resources.
crtc_atomic_check is the final check stage, so beside build a display data
pipeline according the crtc_state, but
From: "james qian wang (Arm Technology China)"
This function builds a display output pipeline according to crtc_state.
And this change only added single pipeline support, the dual pipeline with
slave enabled data flow support will be added in the following change.
v2: Rebase
Signed-off-by: Jame
From: "james qian wang (Arm Technology China)"
A komeda flush is comprised two steps:
1. update pipeline/component state to HW.
2. call dev_func->flush to notify HW to kickoff the update.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c |
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)
---
.../gpu/d
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)
---
.../
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 i
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
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)"
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
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 +
.../gpu/drm/arm/display
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 +
drivers/gpu/drm/arm/displ
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
> > > > >
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 01:07:4
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 gues
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 +-
> 1
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
> ---
> drivers/gpu/drm/i915/intel_tv.c
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: Imre
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, 12
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
> ---
> drivers/gpu/drm/i9
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:
> > > > O
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,
> > >
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 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 modes
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 Dea
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 f
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 actually
1 - 100 of 176 matches
Mail list logo
