On Mon, Jul 1, 2019 at 1:45 PM Rob Clark wrote:
>
> On Mon, Jul 1, 2019 at 10:39 AM Jeffrey Hugo wrote:
> >
> > Creating the msm gem address space requires a reference to the dev where
> > the iommu is located. The driver currently assumes this is the same as
> > the platform device, which break
On Mon, Jul 1, 2019 at 10:41 AM Jeffrey Hugo wrote:
>
> When assigning a mixer, we will iterate through the entire list looking for
> a suitable match. This results in selecting the last match. We should
> stop at the first match, since lower numbered mixers will typically have
> more capabiliti
On Mon, Jul 1, 2019 at 10:45 AM Jeffrey Hugo wrote:
>
> Add support for MDP5 version v3.0 found on msm8998.
>
> Signed-off-by: Jeffrey Hugo
> ---
>
> 8998 support could probably be MDP5 or DPU. This MDP5 support works,
> but may not support all of the features that 8998 supports. However,
> DPU
On Mon, Jul 1, 2019 at 10:39 AM Jeffrey Hugo wrote:
>
> Creating the msm gem address space requires a reference to the dev where
> the iommu is located. The driver currently assumes this is the same as
> the platform device, which breaks when the iommu is outside of the
> platform device. Use th
On Mon, Jul 1, 2019 at 12:07 PM Jeffrey Hugo wrote:
>
> On 7/1/2019 12:58 PM, Rob Clark wrote:
> > On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote:
> >>
> >> On 6/30/2019 9:01 AM, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Do an extra enable/disable cycle at init, to get the clks into
On 7/1/2019 12:58 PM, Rob Clark wrote:
On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote:
On 6/30/2019 9:01 AM, Rob Clark wrote:
From: Rob Clark
Do an extra enable/disable cycle at init, to get the clks into disabled
state in case bootloader left them enabled.
In case they were already en
On Mon, Jul 1, 2019 at 11:25 AM Eric Anholt wrote:
>
> Rob Clark writes:
>
> > From: Rob Clark
> >
> > The goal here is to support inheriting a display setup by bootloader,
> > although there may also be some non-display related use-cases.
> >
> > Rough idea is to add a flag for clks and power d
On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote:
>
> On 6/30/2019 9:01 AM, Rob Clark wrote:
> > From: Rob Clark
> >
> > Do an extra enable/disable cycle at init, to get the clks into disabled
> > state in case bootloader left them enabled.
> >
> > In case they were already enabled, the clk_pre
On 6/30/2019 9:01 AM, Rob Clark wrote:
From: Rob Clark
Request the enable gpio ASIS to avoid disabling bridge during probe, if
already enabled. And if already enabled, defer enabling runpm until
attach to avoid cutting off the power to the bridge.
Once we get to attach, we know panel and drm
On 6/30/2019 9:01 AM, Rob Clark wrote:
From: Rob Clark
Do an extra enable/disable cycle at init, to get the clks into disabled
state in case bootloader left them enabled.
In case they were already enabled, the clk_prepare_enable() has no real
effect, other than getting the enable_count/prepare
On Sun, Jun 30, 2019 at 9:03 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Prep work for the following patch.
>
> Signed-off-by: Rob Clark
Reviewed-by: Jeffrey Hugo
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.or
Rob Clark writes:
> From: Rob Clark
>
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and which
On Sun, Jun 30, 2019 at 9:02 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Mark power domains that may be enabled by bootloader, and which should
> not be disabled until a driver takes them over.
>
> This keeps efifb alive until the real driver can be probed. In a distro
> kernel, the driver will
On Sun, Jun 30, 2019 at 9:02 AM Rob Clark wrote:
>
> From: Rob Clark
>
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enable
Add support for MDP5 version v3.0 found on msm8998.
Signed-off-by: Jeffrey Hugo
---
8998 support could probably be MDP5 or DPU. This MDP5 support works,
but may not support all of the features that 8998 supports. However,
DPU seems to only support 845 (MDP v4.0) with fundamental assumptions
ab
When assigning a mixer, we will iterate through the entire list looking for
a suitable match. This results in selecting the last match. We should
stop at the first match, since lower numbered mixers will typically have
more capabilities, and are likely to be what the bootloader used, if we
are lo
Creating the msm gem address space requires a reference to the dev where
the iommu is located. The driver currently assumes this is the same as
the platform device, which breaks when the iommu is outside of the
platform device. Use the drm_device instead, which happens to always have
a reference
Hi!
It's the final week to submit your talks, workshops or demos for
#XDC2019!!
CfP ends this coming Sunday, July 7!
Have some new developments to share? Facing some challenges with you
projects? If it's related to open source graphics, please send it in!
http://xdc2019.x.org
Best,
Mark
On Mon, 1 Jul 2019 at 13:37, Emil Velikov wrote:
>
> Hi Fuqian,
>
> On Mon, 1 Jul 2019 at 08:13, Fuqian Huang wrote:
> >
> > Using dev_get_drvdata directly.
> >
> > Signed-off-by: Fuqian Huang
> > ---
> > drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> > drivers/gpu/drm/msm/disp/
On Mon, Jul 01, 2019 at 11:22:35AM +0800, Fuqian Huang wrote:
> Using dev_get_drvdata directly.
msm parts LGTM. If you split the patches feel free to add my
Acked-by: Jordan Crouse
> Signed-off-by: Fuqian Huang
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> drivers/gp
On Mon, Jul 1, 2019 at 7:03 AM Rob Herring wrote:
>
> On Sun, Jun 30, 2019 at 2:36 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > The panel-id property in chosen can be used to communicate which panel,
> > of multiple possibilities, is installed.
> >
> > Signed-off-by: Rob Clark
> > ---
>
Hi
Am 01.07.19 um 15:27 schrieb Andrzej Pietrasiewicz:
> Hi Thomas,
>
> Thank you for your comments. Please see inline.
>
> W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze:
>> Hi
>>
>> I like the idea, but would prefer a more structured approach.
>>
>> Setting connector->ddc before calling dr
On 7/1/2019 8:03 AM, Rob Herring wrote:
On Sun, Jun 30, 2019 at 2:36 PM Rob Clark wrote:
From: Rob Clark
The panel-id property in chosen can be used to communicate which panel,
of multiple possibilities, is installed.
Signed-off-by: Rob Clark
---
Documentation/devicetree/bindings/chosen.
On Sun, Jun 30, 2019 at 2:36 PM Rob Clark wrote:
>
> From: Rob Clark
>
> The panel-id property in chosen can be used to communicate which panel,
> of multiple possibilities, is installed.
>
> Signed-off-by: Rob Clark
> ---
> Documentation/devicetree/bindings/chosen.txt | 69
Hi Fuqian,
Thank you for the pach.
On Mon, Jul 01, 2019 at 11:22:35AM +0800, Fuqian Huang wrote:
> Using dev_get_drvdata directly.
This could be expanded a bit. Maybe
"Several drivers cast a struct device pointer to a struct
platform_device pointer only to then call platform_get_drvdata(). Thes
Hi Thomas,
Thank you for your comments. Please see inline.
W dniu 30.06.2019 o 10:12, Thomas Zimmermann pisze:
Hi
I like the idea, but would prefer a more structured approach.
Setting connector->ddc before calling drm_sysfs_connector_add() seems
error prone. The dependency is not really clear
Hi Fuqian,
On Mon, 1 Jul 2019 at 08:13, Fuqian Huang wrote:
>
> Using dev_get_drvdata directly.
>
> Signed-off-by: Fuqian Huang
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
> drivers/gpu/drm/msm/disp/m
Using dev_get_drvdata directly.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 13 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c| 6 ++
drivers/gpu/drm/msm/dsi/dsi_host.c
On 2019-06-26 03:10, Jeykumar Sankaran wrote:
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder spinlock should be initialized during dpu encoder
init instead of dpu encoder setup which is part
29 matches
Mail list logo
