Re: [PATCH] drm: Split out drm_probe_helper.h
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 the includes it has. > > > Maybe a todo, care to pls create that patch since it's your idea? > > > > The main reason I bailed out initially was that this would create > > small changes to several otherwise seldomly touched files. > > And then we would later come and remove drmP.h - so lots of > > small but incremental changes to the same otherwise seldomly > > edited files. > > And the job was only partially done. > > > > I will try to experiment with an approach where I clean up the > > include/drm/*.h files a little (like suggested above, +delete drmP.h > > and maybe a bit more). > > > > Then to try on a driver by driver basis to make it build with a > > cleaned set of include files. > > I hope that the cleaned up driver can still build without the > > cleaned header files so the changes can be submitted piecemal. > > > > Will do so with an eye on the lesser maintained drivers to try it > > out to avoid creating too much chrunch for others. > > I have now a few patches queued, but the result is not too pretty. > I did the following: > > - For all files in include/drm/*.h the set of include files > were adjusted to the minimum number of files required to make > them build without any other files included first. > > Created one .c file for each .h file. Then included the .h > file and adjusted to the minimal set of include files. > In the process a lot of forwards were added. > > - Deleted drmP.h > > - Fixed build of a few drivers: sti, tilcdc, gma500, tve200, via > > Some observations: > > - Killing all the includes not needed in the headers files > results in a a lot of extra changes. > Examples: > drm_modseset_helper_vtables.h is no longer > included by anyone, so needs to be added in many files > > drm_atomic_state_helper.h is no longer included > by anyone so likewise needs to be added in many files > > - It is very tedious to do this properly. > The process I followed was: > - delete / comment out all include files > - add back the obvious from a quick scan of the code > - build - fix - build - fix - build - fix ... > - next file... > > - The result is errorprone as only the allyesconfig + allmodconfig > variants are tested. But reallife configurations are more diverse. > > Current diffstat: >111 files changed, 771 insertions(+), 401 deletions(-) > > This is for the 5 drivers alone and not the header cleanup. > So long story short - this is not good and not the way forward. > > I will try to come up with a few improvements to make the > headers files selfcontained, but restricted to the changes that > add forwards/include to avoid the chrunch in all the drivers. > > And then post for review a few patches to clean up some headers. > If the cleanup gets a go I will try to persuade the introduction > of these. > This will include, but will not be limited to, the above mentioned > drm_crtc_helper.h header file. > > For now too much time was already spent on this, so it is at the > moment pushed back on my TODO list. > This mail serve also as a kind of "where had I left", when/if I > pick this up again. > > If there are anyone that knows some tooling that can help in the > process of adjusting the header files I am all ears. Yeah in the process of splitting up drmP.h we've created a few smaller such piles of headers. I think in some cases it's just not going to be worth it to fully split them up, e.g. drm_crtc_helper.h is going to be a pure legacy helper, only needed by pre-atomic drivers. Splitting that up doesn't seem to useful to me. Similarly we might want drm_atomic_helper.h to keep pulling in the other helper headers. So probably going to be a judgement call on a case-by-case basis. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] drm: Remove unused Renesas SH Mobile DRM driver
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 05:22:58PM +0100, Geert Uytterhoeven wrote:
> > >>> Since its incarnation in v3.7 almost 7 years ago, no users of the SH
> > >>> Mobile DRM driver have appeared.
> > >>>
> > >>> Hence remove the driver. It can be resurrected from git history,
> > >>> if/when needed.
> > >>>
> > >>> Signed-off-by: Geert Uytterhoeven
> > >>
> > >> I'd prefer removing the fbdev variant tbh ...
> > >
> > > I understand ;-)
> > >
> > > But sh_mobile_lcdc_fb is used on 5 legacy SuperH platforms, and 1 ARM
> > > platform. At least the latter is working fine.
> > >
> > >> Not sure why exactly the switch never happened.
> > >
> > > Me neither. I^HGoogle can't even find posted patches of board
> > > integration.
> > >
> > > Note that both drivers lack DT support, which would be very desirable on
> > > ARM, as graphics is the single remaining working driver on the Atmark
> > > Techno Armadillo 800 EVA board not using DT.
> >
> > Ah I wondered why the drm driver isn't just automatically picked up in
> > today's neat world of DT (if you enable it in .config instead of the fbdev
> > one). It's not even using DT yet :-/
>
> I'd prefer dropping the fbdev driver too, but that would require porting
> the SH boards to the DRM driver, and implement DT support for the ARM
> board. I don't think anyone is willing to invest time in this, so I'm
> fine dropping this driver as the boards are pretty much dead. I would,
> however, also drop the fbdev driver in that case.
I agree the SH boards are pretty much dead.
However, derivatives of the Armadillo-800 EVA board are still available[1],
and even received a product update last month[2].
A relative made it to the International Space Station in 2017[3].
[1] https://armadillo.atmark-techno.com/products
[2] https://armadillo.atmark-techno.com/armadillo-840
[3] https://lists.freedesktop.org/archives/gstreamer-devel/2017-July/064696.html
BTW, do you still have the prototype integration patches for the DRM driver,
presumably for SH-Mobile AP4?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/dp: use DRM_DEBUG_DP() instead of drm_dbg for logging
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 | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 26835d174939..4def0bface85 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -194,11 +194,11 @@ drm_dp_dump_access(const struct drm_dp_aux *aux,
>> const char *arrow = request == DP_AUX_NATIVE_READ ? "->" : "<-";
>>
>> if (ret > 0)
>> -drm_dbg(DRM_UT_DP, "%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
>> -aux->name, offset, arrow, ret, min(ret, 20), buffer);
>> +DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d) %*ph\n",
>> + aux->name, offset, arrow, ret, min(ret, 20),
>> buffer);
>> else
>> -drm_dbg(DRM_UT_DP, "%s: 0x%05x AUX %s (ret=%3d)\n",
>> -aux->name, offset, arrow, ret);
>> +DRM_DEBUG_DP("%s: 0x%05x AUX %s (ret=%3d)\n",
>> + aux->name, offset, arrow, ret);
>> }
>>
>> /**
>> --
>> 2.20.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Enhance dma-fence tracing
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 these common dma-fence level tracepoints, the userspace tools can > establish a detailed view of the client <-> HW flow across different > kernels. There is a strong ask to have this available, so that the > userspace developer can effectively assess if they're doing a good job > about feeding the beast of a GPU hardware. > > In the case of needing to look into more fine-grained details of how > kernel internals work towards the goal of feeding the beast, the tools > may optionally amend the dma-fence tracing information with the driver > implementation specific. But for such cases, the tools should have a > graceful degradation in case the expected extra tracepoints have > changed or their format differs from the expected, as the kernel > implementation internals are not expected to stay the same. > > It is important to distinguish between tracing for the purpose of client > flow visualisation and tracing for the purpose of low-level kernel > debugging. The latter is highly implementation specific, tied to > a particular HW and driver, whereas the former addresses a common goal > of user level tracing and likely a common set of userspace tools. > Having made the distinction that these tracepoints will be consumed for > client API tooling, we raise the spectre of tracepoint ABI stability. It > is hoped that by defining a common set of dma-fence tracepoints, we avoid > the pitfall of exposing low level details and so restrict ourselves only > to the high level flow that is applicable to all drivers and hardware. > Thus the reserved guarantee that this set of tracepoints will be stable > (with the emphasis on depicting client <-> HW flow as opposed to > driver <-> HW). > > In terms of specific changes to the dma-fence tracing, we remove the > emission of the strings for every tracepoint (reserving them for > dma_fence_init for cases where they have unique dma_fence_ops, and > preferring to have descriptors for the whole fence context). strings do > not pack as well into the ftrace ringbuffer and we would prefer to > reduce the amount of indirect callbacks required for frequent tracepoint > emission. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen > Cc: Tvrtko Ursulin > Cc: Alex Deucher > Cc: "Christian König" > Cc: Eric Anholt > Cc: Pierre-Loup Griffais > Cc: Michael Sartain > Cc: Steven Rostedt In general yes please! If possible please separate out the changes to the common dma_fence infrastructure from the i915 changes. One thing I'm wondering is why the enable_signaling trace point doesn't need to be exported any more. Is that only used internally in the common infrastructure? Apart from that I'm on sick leave today, so give me at least a few days to recover and take a closer look. Thanks, Christian. > --- > drivers/dma-buf/dma-fence.c | 9 +- > drivers/gpu/drm/i915/i915_gem_clflush.c | 5 + > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 - > drivers/gpu/drm/i915/i915_request.c | 16 +- > drivers/gpu/drm/i915/i915_timeline.c| 5 + > drivers/gpu/drm/i915/i915_trace.h | 134 --- > drivers/gpu/drm/i915/intel_guc_submission.c | 10 ++ > drivers/gpu/drm/i915/intel_lrc.c| 6 + > drivers/gpu/drm/i915/intel_ringbuffer.h | 2 + > include/trace/events/dma_fence.h| 177 +++- > 10 files changed, 214 insertions(+), 151 deletions(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 3aa8733f832a..5c93ed34b1ff 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -27,8 +27,15 @@ > #define CREATE_TRACE_POINTS > #include > > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_context_create); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_context_destroy); > + > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_await); > EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); > -EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_execute_start); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_execute_end); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_wait_start); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_wait_end); > > static DEFINE_SPINLOCK(dma_fence_stub_lock); > static struct dma_fence dma_fence_stub; > diff --git a/drivers/gpu/drm/i915/i915_gem_clflush.c > b/drivers/gpu/drm/i915/i915_gem_clflush.c > index 8e74c23cbd91..435c1303ecc8 100644 > --- a/drivers/gpu/drm/i915/i915_gem_clflush.c > +++ b/drivers/gpu/drm/i915/i915_gem_clflush.c > @@ -22,6 +22,8 @@ >* >*/ > > +#include > + > #include "i915_drv.h" > #include "intel_frontbuffer.h" > #include "i915_gem_clflush.h" > @@ -73,6 +75,7 @@ static void i915_clflush_work(
Re: [PATCH] drm/doc: Make igts for cross-driver stuff mandatory
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 at 05:39:03PM +0100, 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 in the RFC discussions). > > > > > > > > > > - tests reorganized into subdirectories so that the i915-gem tests > > > > > don't clog the main/shared tests directory anymore > > > > > > > > > > - quite a few more non-intel people contributing/reviewing/committing > > > > > igt tests patches. > > > > > > > > > > I think this addresses all the concerns raised in the RFC discussions, > > > > > and assuming there's enough Acks and no new issues that pop up, we can > > > > > go ahead with this. > > > > > > > > > > 1: https://patchwork.kernel.org/patch/10648851/ > > > > > Cc: Petri Latvala > > > > > Cc: Arkadiusz Hiler > > > > > Cc: Liviu Dudau > > > > > Cc: Sean Paul > > > > > Cc: Eric Anholt > > > > > Cc: Alex Deucher > > > > > Cc: Dave Airlie > > > > > Signed-off-by: Daniel Vetter > > > > > --- > > > > > Documentation/gpu/drm-uapi.rst | 7 +++ > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > diff --git a/Documentation/gpu/drm-uapi.rst > > > > > b/Documentation/gpu/drm-uapi.rst > > > > > index a752aa561ea4..413915d6b7d2 100644 > > > > > --- a/Documentation/gpu/drm-uapi.rst > > > > > +++ b/Documentation/gpu/drm-uapi.rst > > > > > @@ -238,6 +238,13 @@ DRM specific patterns. Note that ENOTTY has the > > > > > slightly unintuitive meaning of > > > > > Testing and validation > > > > > == > > > > > > > > > > +Testing Requirements for userspace API > > > > > +-- > > > > > + > > > > > +New cross-driver userspace interface extensions, like new IOCTL, new > > > > > KMS > > > > > +properties, new files in sysfs or anything else that constitutes an > > > > > API change > > > > > +need to have driver-agnostic testcases in IGT for that feature. > > > > > > > > From an aspirational point of view I am fine with this and you can have > > > > my Acked-by: Liviu Dudau . > > > > > > > > From a practical point of view I would like to see a matrix of KMS APIs > > > > that are being validated and the drivers that have been tested. > > > > Otherwise, > > > > the next person that comes and tries to add a new IOCTL, KMS property > > > > or new > > > > file in sysfs is going to discover that he has subscribed to a much > > > > bigger > > > > task of getting enough KMS drivers testable in the first place. > > > > > > This is what the _new_ features is about, no expectation to write > > > tests for all the existing stuff. Although I think there's not really > > > any big gaps in igt anymore, we do have at least some (rather rough > > > and coarse in some case) test coverage for everything I think. Should > > > this be clarified further? > > > -Daniel > > > > > > > I share a similar view to Liviu here. I think this new requirement > > raises the bar more than you intended. > > > > By saying that all new features must be tested by igt, you're also > > implying that a driver must run igt (at some basic level); before the > > developers working on that driver can start trying to implement new > > features. That puts an additional hurdle in the way of adding stuff > > to KMS for people who aren't already using igt. > > > > I'm all for testing, and UAPI being well proven before we merge it, > > and even for a central KMS test suite. However, when we (Arm Mali-DP > > people) have tried to implement things in igt it's been a battle, > > because of various built-in assumptions which it made. > > > > For example, most meaningful igt tests rely on CRC. Much of our HW > > doesn't have CRC. CRC could be implemented in theory using writeback, > > but that currently doesn't exist. That means you're effectively saying > > that we (Arm) can't implement any new cross-device KMS features until > > we've either: > > > > a) also implemented writeback-based CRC in igt OR > > b) implemented the new feature in someone else's driver which does > > support CRC. > > We didn't just pick crcs for lols (or because that's all intel > supports), we picked it because it will work for both hw with crc and > hw with writeback. I checked with a pile of driver writers way back > (over irc), and the interface we picked is something pretty much all > display blocks (except the _very_ simple ones) should be able to > support. Same discussion also happened again when made the crc > interfaces in debugfs more generic. > > > That seems a bit out of order to
[PATCH] pwm: Add MediaTek MT8183 display PWM driver support
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
---
drivers/pwm/pwm-mtk-disp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 893940d45f0d..15803c71fe80 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -277,10 +277,21 @@ static const struct mtk_pwm_data mt8173_pwm_data = {
.commit_mask = 0x1,
};
+static const struct mtk_pwm_data mt8183_pwm_data = {
+ .enable_mask = BIT(0),
+ .con0 = 0x18,
+ .con0_sel = 0x0,
+ .con1 = 0x1c,
+ .has_commit = false,
+ .bls_debug = 0x80,
+ .bls_debug_mask = 0x3,
+};
+
static const struct of_device_id mtk_disp_pwm_of_match[] = {
{ .compatible = "mediatek,mt2701-disp-pwm", .data = &mt2701_pwm_data},
{ .compatible = "mediatek,mt6595-disp-pwm", .data = &mt8173_pwm_data},
{ .compatible = "mediatek,mt8173-disp-pwm", .data = &mt8173_pwm_data},
+ { .compatible = "mediatek,mt8183-disp-pwm", .data = &mt8183_pwm_data},
{ }
};
MODULE_DEVICE_TABLE(of, mtk_disp_pwm_of_match);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] pwm: Add MediaTek MT8183 display PWM driver support
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
---
drivers/pwm/pwm-mtk-disp.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/pwm/pwm-mtk-disp.c b/drivers/pwm/pwm-mtk-disp.c
index 893940d45f0d..15803c71fe80 100644
--- a/drivers/pwm/pwm-mtk-disp.c
+++ b/drivers/pwm/pwm-mtk-disp.c
@@ -277,10 +277,21 @@ static const struct mtk_pwm_data mt8173_pwm_data = {
.commit_mask = 0x1,
};
+static const struct mtk_pwm_data mt8183_pwm_data = {
+ .enable_mask = BIT(0),
+ .con0 = 0x18,
+ .con0_sel = 0x0,
+ .con1 = 0x1c,
+ .has_commit = false,
+ .bls_debug = 0x80,
+ .bls_debug_mask = 0x3,
+};
+
static const struct of_device_id mtk_disp_pwm_of_match[] = {
{ .compatible = "mediatek,mt2701-disp-pwm", .data = &mt2701_pwm_data},
{ .compatible = "mediatek,mt6595-disp-pwm", .data = &mt8173_pwm_data},
{ .compatible = "mediatek,mt8173-disp-pwm", .data = &mt8173_pwm_data},
+ { .compatible = "mediatek,mt8183-disp-pwm", .data = &mt8183_pwm_data},
{ }
};
MODULE_DEVICE_TABLE(of, mtk_disp_pwm_of_match);
--
2.12.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Enhance dma-fence tracing
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 for most client API > > level flow visualisation. > > > > With these common dma-fence level tracepoints, the userspace tools can > > establish a detailed view of the client <-> HW flow across different > > kernels. There is a strong ask to have this available, so that the > > userspace developer can effectively assess if they're doing a good job > > about feeding the beast of a GPU hardware. > > > > In the case of needing to look into more fine-grained details of how > > kernel internals work towards the goal of feeding the beast, the tools > > may optionally amend the dma-fence tracing information with the driver > > implementation specific. But for such cases, the tools should have a > > graceful degradation in case the expected extra tracepoints have > > changed or their format differs from the expected, as the kernel > > implementation internals are not expected to stay the same. > > > > It is important to distinguish between tracing for the purpose of client > > flow visualisation and tracing for the purpose of low-level kernel > > debugging. The latter is highly implementation specific, tied to > > a particular HW and driver, whereas the former addresses a common goal > > of user level tracing and likely a common set of userspace tools. > > Having made the distinction that these tracepoints will be consumed for > > client API tooling, we raise the spectre of tracepoint ABI stability. It > > is hoped that by defining a common set of dma-fence tracepoints, we avoid > > the pitfall of exposing low level details and so restrict ourselves only > > to the high level flow that is applicable to all drivers and hardware. > > Thus the reserved guarantee that this set of tracepoints will be stable > > (with the emphasis on depicting client <-> HW flow as opposed to > > driver <-> HW). > > > > In terms of specific changes to the dma-fence tracing, we remove the > > emission of the strings for every tracepoint (reserving them for > > dma_fence_init for cases where they have unique dma_fence_ops, and > > preferring to have descriptors for the whole fence context). strings do > > not pack as well into the ftrace ringbuffer and we would prefer to > > reduce the amount of indirect callbacks required for frequent tracepoint > > emission. > > > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Cc: Tvrtko Ursulin > > Cc: Alex Deucher > > Cc: "Christian König" > > Cc: Eric Anholt > > Cc: Pierre-Loup Griffais > > Cc: Michael Sartain > > Cc: Steven Rostedt > > In general yes please! If possible please separate out the changes to > the common dma_fence infrastructure from the i915 changes. Sure, I was just stressing the impact: remove some randomly placed internal debugging tracepoints, try to define useful ones instead :) On the list of things to do was to convert at least 2 other drivers (I was thinking nouveau/msm for simplicity, vc4 for a simpler introduction to drm_sched than amdgpu) over to be sure we have the right tracepoints. > One thing I'm wondering is why the enable_signaling trace point doesn't > need to be exported any more. Is that only used internally in the common > infrastructure? Right. Only used inside the core, and I don't see much call for making it easy for drivers to fiddle around bypassing the core enable_signaling/signal. (I'm not sure it's useful for client flow either, it feels more like dma-fence debugging, but they can just not listen to that tracepoint.) -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108317] [GCN3] Black Textures only on GCN3 in Cemu Zelda Breath of the Wild (OpenGL 4.5)
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. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Enhance dma-fence tracing
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 framework > > > should include the tracing infrastructure required for most client API > > > level flow visualisation. > > > > > > With these common dma-fence level tracepoints, the userspace tools can > > > establish a detailed view of the client <-> HW flow across different > > > kernels. There is a strong ask to have this available, so that the > > > userspace developer can effectively assess if they're doing a good job > > > about feeding the beast of a GPU hardware. > > > > > > In the case of needing to look into more fine-grained details of how > > > kernel internals work towards the goal of feeding the beast, the tools > > > may optionally amend the dma-fence tracing information with the driver > > > implementation specific. But for such cases, the tools should have a > > > graceful degradation in case the expected extra tracepoints have > > > changed or their format differs from the expected, as the kernel > > > implementation internals are not expected to stay the same. > > > > > > It is important to distinguish between tracing for the purpose of client > > > flow visualisation and tracing for the purpose of low-level kernel > > > debugging. The latter is highly implementation specific, tied to > > > a particular HW and driver, whereas the former addresses a common goal > > > of user level tracing and likely a common set of userspace tools. > > > Having made the distinction that these tracepoints will be consumed for > > > client API tooling, we raise the spectre of tracepoint ABI stability. It > > > is hoped that by defining a common set of dma-fence tracepoints, we avoid > > > the pitfall of exposing low level details and so restrict ourselves only > > > to the high level flow that is applicable to all drivers and hardware. > > > Thus the reserved guarantee that this set of tracepoints will be stable > > > (with the emphasis on depicting client <-> HW flow as opposed to > > > driver <-> HW). > > > > > > In terms of specific changes to the dma-fence tracing, we remove the > > > emission of the strings for every tracepoint (reserving them for > > > dma_fence_init for cases where they have unique dma_fence_ops, and > > > preferring to have descriptors for the whole fence context). strings do > > > not pack as well into the ftrace ringbuffer and we would prefer to > > > reduce the amount of indirect callbacks required for frequent tracepoint > > > emission. > > > > > > Signed-off-by: Chris Wilson > > > Cc: Joonas Lahtinen > > > Cc: Tvrtko Ursulin > > > Cc: Alex Deucher > > > Cc: "Christian König" > > > Cc: Eric Anholt > > > Cc: Pierre-Loup Griffais > > > Cc: Michael Sartain > > > Cc: Steven Rostedt > > > > In general yes please! If possible please separate out the changes to > > the common dma_fence infrastructure from the i915 changes. > > Sure, I was just stressing the impact: remove some randomly placed > internal debugging tracepoints, try to define useful ones instead :) > > On the list of things to do was to convert at least 2 other drivers > (I was thinking nouveau/msm for simplicity, vc4 for a simpler > introduction to drm_sched than amdgpu) over to be sure we have the right > tracepoints. I think sprinkling these over the scheduler (maybe just as an opt-in, for the case where the driver doesn't have some additional queueing somewhere) would be good. I haven't checked whether it fits, but would give you a bunch of drivers at once. It might also not cover all the cases (I guess the wait related ones would need to be somewhere else). -Daniel > > One thing I'm wondering is why the enable_signaling trace point doesn't > > need to be exported any more. Is that only used internally in the common > > infrastructure? > > Right. Only used inside the core, and I don't see much call for making > it easy for drivers to fiddle around bypassing the core > enable_signaling/signal. (I'm not sure it's useful for client flow > either, it feels more like dma-fence debugging, but they can just > not listen to that tracepoint.) > -Chris > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V2] pwm: Add MediaTek MT8183 display PWM driver support
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 commit mode > and use PWM_PERIOD/PWM_HIGH_WIDTH. > > Signed-off-by: Jitao Shi There is no difference compared to (implicit) v1 sent a few minutes earlier, right? There was another patch sent with the same Subject last week, so I assume the mail from today without "v2" in the Subject was a mistake? > --- Adding a paragraph below the tripple dash that points out what was changed compared to the previous submission is a good idea to help reviewers to more easily see what was changed. I guess you only adapted the commit log as a reaction to Matthias Burgger's review? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/sun4i: hdmi: Fix usage of TMDS clock
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 TDMS clock being parent clock for DDC clock, TDMS clock
> was turned on/off for each EDID probe, causing spurious failures
> for certain HDMI/DVI screens.
>
> Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
>
> Signed-off-by: Priit Laes
> ---
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index 061d2e0d9011..25f4d676fd82 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -92,6 +92,8 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
> val = readl(hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> val &= ~SUN4I_HDMI_VID_CTRL_ENABLE;
> writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> +
> + clk_disable_unprepare(hdmi->tmds_clk);
> }
>
> static void sun4i_hdmi_enable(struct drm_encoder *encoder)
> @@ -112,6 +114,8 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder)
> val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
>
> writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
> +
> + clk_prepare_enable(hdmi->tmds_clk);
We'll probably need to enable that clock to send the infoframes as
well. I moved it earlier (and that allows the enable and disable
function to be symetric as well).
Thanks for figuring this out!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
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: > This whole issue keeps getting more and more confusing. Well, I don't really do DMA here, but instead the buffers in question are shared with other Xen domain, so effectively it could be thought of some sort of DMA here, where the "device" is that remote domain. If the buffers are not flushed then the remote part sees some inconsistency which in my case results in artifacts on screen while displaying the buffers. When buffers are allocated via DMA API then there are no artifacts; if buffers are allocated with shmem + DMA mapping then there are no artifacts as well. The only offending use-case is when I use shmem backed buffers, but do not flush them >>> The right answer would be to implement cache maintainance hooks for >>> this case in the Xen arch code. These would basically look the same >>> as the low-level cache maintainance used by the DMA ops, but without >>> going through the DMA mapping layer, in fact they should probably >>> reuse the same low-level assembly routines. >>> >>> I don't think this is the first usage of such Xen buffer sharing, so >>> what do the other users do? >> I'll have to get even deeper into it. Initially I >> looked at the code, but didn't find anything useful. >> Or maybe I have just overlooked obvious things there > From Xen on Arm ABI: > > "All memory which is shared with other entities in the system > (including the hypervisor and other guests) must reside in memory > which is mapped as Normal Inner Write-Back Outer Write-Back > Inner-Shareable. > This applies to: > - hypercall arguments passed via a pointer to guest memory. > - memory shared via the grant table mechanism (including PV I/O > rings etc). > - memory shared with the hypervisor (struct shared_info, struct > vcpu_info, the grant table, etc). > " > > So you should not need any cache maintenance here. Can you provide > more details on the memory attribute you use for memory shared in both > the backend and frontend? > It takes quite some time to collect this (because many components are involved in the use-case), but for now the pages in the guest domain are: !PTE_RDONLY + PTE_PXN + PTE_SHARED + PTE_AF + PTE_UXN + PTE_ATTRINDX(MT_NORMAL) > Cheers, > >> >> Thank you, >> Oleksandr >> ___ >> Xen-devel mailing list >> xen-de...@lists.xenproject.org >> https://lists.xenproject.org/mailman/listinfo/xen-devel >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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 where we 100% > >> positively know that they actually work. And document that fact > >> in big fat comments. > > > > Well, as I mentioned in my commit log as well, if we default to off > > unless CONFIG_X86, we may break working setups on MIPS and Power where > > the device is in fact non-cache coherent, and relies on this > > 'optimization' to get things working. > > FWIW, the amdgpu driver doesn't rely on non-snooped transfers for > correct basic operation (the scenario Christian brought up is a very > specialized use-case), so that shouldn't be an issue. > The point is that this is only true for x86. On other architectures, the use of non-cached mappings on the CPU side means that you /do/ rely on non-snooped transfers, since if those transfers turn out not to snoop inadvertently, the accesses are incoherent with the CPU's view of memory. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
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. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > > > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes > > > > > > napisal(a): > > > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > > > > > > Currently MP clocks don't consider adjusting parent rate even if > > > > > > > > they > > > > > > > > are allowed to do so. Such behaviour considerably lowers amount > > > > > > > > of > > > > > > > > possible rates, which is very inconvenient when such clock is > > > > > > > > used > > > > > > > > for > > > > > > > > pixel clock, for example. > > > > > > > > > > > > > > > > In order to improve the situation, adjusting parent rate is > > > > > > > > considered > > > > > > > > when allowed. > > > > > > > > > > > > > > > > This code is inspired by clk_divider_bestdiv() function, which > > > > > > > > does > > > > > > > > basically the same thing for different clock type. > > > > > > > > > > > > > > This patch seems to break the eMMC support on Olinuxino-Lime2-eMMC > > > > > > > boards: > > > > > > > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly > > > > > > > filesystem > > > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during recovery > > > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > > > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > > > > > > > > > I'm not familiar with A20. What is interesting is that emmc clocks > > > > > > don't > > > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any > > > > > > difference. > > > > > > > > > > > > Can you post content of clk_summary with and without this patch? > > > > > > > > > > In both cases I booted from FEL with rootfs on sdcard and tried to > > > > > mount > > > > > partition from eMMC to /mnt. With your patch, last step it fails. > > > > > > > > > > pre-patch working: > > > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 is > > > > > off?) > > > > > > > > > > post-patch not working: > > > > > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > > > > > > > > > Also, attached the logs. > > > > > > > > Thanks. Just one more request. Can you enable debug messages in mmc > > > > driver? > > > > I'm interested in output of this line: > > > > > > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", > > > > > > > > clock, rate); > > > > > > 1c11000 is eMMC: > > > [snip] > > > [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > 40 > > > [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded > > > 5200 [2.203340] sunxi-mmc 1c11000.mmc: setting clk to 5200, > > > rounded 5200 [2.211412] sunxi-mmc 1c11000.mmc: setting clk to > > > 5200, rounded 5200 [4.967865] sunxi-mmc 1c11000.mmc: setting > > > clk to 5200, rounded 5200 [8.755345] sunxi-mmc 1c11000.mmc: > > > setting clk to 5200, rounded 5200 [9.082510] sunxi-mmc > > > 1c11000.mmc: setting clk to 5200, rounded 5200 > > > > > > Here I tried to mount partition from eMMC... > > > > > > [ 72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded > > > 5200 [ 72.269629] sunxi-mmc 1c11000.mmc: data error, sending stop > > > command [ 73.268999] sunxi-mmc 1c11000.mmc: send stop command failed > > > [/snip] > > > > > > And clock tree: > > > [snip] > > > pll-periph-base330 12 0 > > > > > > 0 5 pll-periph 660 6 > > > > > >0 0 5 mmc2 330 > > > 5000 > > > 0 0 5 mmc2_sample 110 > > > 5000 0 120 5 mmc2_output 11 > > > 0 > > > 5000 060 5 ahb 18
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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 (IS_ENABLED(CONFIG_PPC))
> > + return IS_ENABLED(CONFIG_NOT_COHERENT_CACHE);
> > + else if (IS_ENABLED(CONFIG_MIPS))
> > + return !IS_ENABLED(CONFIG_CPU_LOONGSON3);
> > + else if (IS_ENABLED(CONFIG_X86))
> > + return true;
> > +
> > + return !dev_is_dma_coherent(ddev->dev);
>
> And even if something like this was valid to do, it would have to be
> a core function with an arch hook, and not hidden in a random driver.
Why would it not be valid to do? Is it wrong for a driver to be aware
of whether a device is cache coherent or not?
And in case it isn't, do you have an alternative suggestion on how to
fix this mess?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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 platform
specific. Whether it /matters/ if NoSnoop is implemented correctly or
not is architecture specific: on x86, such transactions are coherent
with the CPU whether the NoSnoop attribute is honored or not. On other
architectures, it depends on whether such transactions may allocate in
caches that are non-coherent with the CPU's uncached mappings.
Bottom line is that we should not rely on this optimization to work
correctly for cache coherent devices in the general case. On the
other hand, disabling this optimization for non-coherent devices
is likely to cause breakage as well, since the driver will assume
cache coherent PCIe if this optimization is turned off.
So rename drm_arch_can_wc_memory() to drm_device_can_wc_memory(), and
pass the drm_device pointer into it so we can base the return value
on whether the device is cache coherent or not if not running on
X86.
Cc: Christian Koenig
Cc: Alex Deucher
Cc: David Zhou
Cc: Huang Rui
Cc: Junwei Zhang
Cc: Michel Daenzer
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Will Deacon
Reported-by: Carsten Haitzler
Signed-off-by: Ard Biesheuvel
---
This is a followup to '[RFC PATCH] drm/ttm: force cached mappings for system
RAM on ARM'
https://lore.kernel.org/linux-arm-kernel/20190110072841.3283-1-ard.biesheu...@linaro.org/
Without t
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
include/drm/drm_cache.h| 19 +++
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 728e15e5d68a..777fa251838f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -480,7 +480,7 @@ static int amdgpu_bo_do_create(struct amdgpu_device *adev,
/* For architectures that don't support WC memory,
* mask out the WC flag from the BO
*/
- if (!drm_arch_can_wc_memory())
+ if (!drm_device_can_wc_memory(adev->ddev))
bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC;
#endif
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index 833e909706a9..610889bf6ab5 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -249,7 +249,7 @@ int radeon_bo_create(struct radeon_device *rdev,
/* For architectures that don't support WC memory,
* mask out the WC flag from the BO
*/
- if (!drm_arch_can_wc_memory())
+ if (!drm_device_can_wc_memory(rdev->ddev))
bo->flags &= ~RADEON_GEM_GTT_WC;
#endif
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index bfe1639df02d..ced63b1207a3 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -33,6 +33,8 @@
#ifndef _DRM_CACHE_H_
#define _DRM_CACHE_H_
+#include
+#include
#include
void drm_clflush_pages(struct page *pages[], unsigned long num_pages);
@@ -41,15 +43,16 @@ void drm_clflush_virt_range(void *addr, unsigned long
length);
u64 drm_get_max_iomem(void);
-static inline bool drm_arch_can_wc_memory(void)
+static inline bool drm_device_can_wc_memory(struct drm_device *ddev)
{
-#if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
- return false;
-#elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3)
- return false;
-#else
- return true;
-#endif
+ if (IS_ENABLED(CONFIG_PPC))
+ return IS_ENABLED(CONFIG_NOT_COHERENT_CACHE);
+ else if (IS_ENABLED(CONFIG_MIPS))
+ return !IS_ENABLED(CONFIG_CPU_LOONGSON3);
+ else if (IS_ENABLED(CONFIG_X86))
+ return true;
+
+ return !dev_is_dma_coherent(ddev->dev);
}
#endif
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] dt-bindings: display: armada: Add display subsystem binding
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 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
> > > > > ---
> > > > > .../display/armada/marvell-armada-drm.txt | 24
> > > > > +++
> > > > > 1 file changed, 24 insertions(+)
> > > > >
> > > > > diff --git
> > > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > >
> > > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > index de4cca9432c8..3dbfa8047f0b 100644
> > > > > ---
> > > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > +++
> > > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > @@ -1,3 +1,27 @@
> > > > > +Marvell Armada DRM master device
> > > > > +
> > > > > +
> > > > > +The Marvell Armada DRM master device is a virtual device needed to
> > > > > list all
> > > > > +nodes that comprise the graphics subsystem.
> > > > > +
> > > > > +Required properties:
> > > > > +
> > > > > + - compatible: value should be "marvell,dove-display-subsystem",
> > > > > + "marvell,armada-display-subsystem"
> > > > > + - ports: a list of phandles pointing to display interface ports of
> > > > > CRTC
> > > > > + devices
> > > > > + - memory-region: phandle to a node describing memory to be used for
> > > > > the
> > > > > + framebuffer
> > > > > +
> > > > > +Example:
> > > > > +
> > > > > + display-subsystem {
> > > > > + compatible = "marvell,dove-display-subsystem",
> > > > > +"marvell,armada-display-subsystem";
> > > > > + memory-region = <&display_reserved>;
> > > > > + ports = <&lcd0_port>;
> > > >
> > > > If there is only one device, you don't need this virtual node.
> > >
> > > By "one device" you mean one LCD controller (CRTC)?
> >
> > Yes.
>
> How does that work (as far as the Linux implementation) ? I can't see
> a way that could work, while allowing the flexibility that Armada DRM
> allows (two completely independent LCD controllers as two separate DRM
> devices vs one DRM device containing both LCD controllers.)
>
> > > I suppose in the (single CRTC) example case, the display-subsystem node
> > > used to associate it with the memory region reserved for allocating the
> > > frame buffers from. Could that be done differently?
> >
> > Move memory-region to the LCD controller node.
>
> That doesn't work - it would appear in the wrong part of the driver.
>
> > > Also, if the node is indeed made optional, then it's going to
> > > complicate things on the DRM side. Currently the driver that binds to
> > > the node creates the DRM device once it sees all the components
> > > connected to the ports appear. If we loose it, then the LCD controller
> > > driver would somehow need to find out that it's alone and create the
> > > DRM device itself.
> >
> > DT is not the only way to create devices. The DRM driver can bind to
> > the LCDC node and then create a child CRTC device (or even multiple
> > ones for h/w with multiple pipelines).
>
> That seems completely upside down and rediculous to me - are you
> really suggesting that we should have some kind of virtual device
> in DT, and omit the _real_ physical devices for that, having the
> driver create the device with all the appropriate SoC resources?
Hmm, that's not how I read that. My understanding (putting aside
practicality of the solution) is that Rob was merely suggesting that
for the single LCDC case there would be just a single LCDC node in DT
and the driver that binds to it would create the DRM device & CRTC
device pair.
> > You'll also notice that there are only 3 cases of this virtual node in
> > the tree: STi, i.MX IPU, and Rockchip. That's because we've deprecated
> > doing these virtual nodes for some time now. IOW, there are several
> > examples of how to do this without a virtual node.
>
> This driver has been in-tree with this setup for some time, although
> the documentation has been missing (we actually have a _lot_ of
> instances of that.) However, we have no in-tree DT using it.
>
> I don't really see how to satisfy your comments without totally
> restructuring the driver, which is going to be quite a big chunk
> of work. I'm not sure I have the motivation to do that right now.
Note that the initial objection was against the display-subsystem node
being mandatory if "there is only one [LCDC] device".
My understanding is that need to include the display-subsystem node for
the mu
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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 actually work. And document that fact > > > in big fat comments. > > > > Well, as I mentioned in my commit log as well, if we default to off > > unless CONFIG_X86, we may break working setups on MIPS and Power where > > the device is in fact non-cache coherent, and relies on this > > 'optimization' to get things working. The same could be true for > > non-coherent ARM systems, hence my approach to disable this hack for > > cache coherent devices on non-X86 only. > > Do we break existing setups or just reduce performance due to the lack > of WC mappings? I thought it was the latter. Combining this check #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE) return false; ... #else return true; #endif with the fact that the driver assumes that DMA is cache coherent, I'd be surprised if this hardware works without the hack. The optimization targets cache coherent systems where pushing data through the cache into the GPU is wasteful, given that it evicts other data and relies on snooping by the device. In this case, disabling the optimization reduces performance. My point is that it is highly likely that non-cache coherent systems may accidentally be in a working state only due to this optimization, and not because the driver deals with non-cache coherent DMA correctly. > The point is that > even your check won't do what you actually said. Well, it enables the optimization only for non-cache coherent devices. How is that different from what I said? > At lot of non-loongson > mips platforms are not cache coherent. You are assuming that whoever added that check cared about other MIPS platforms > As are a lot of arm setups > and all sparc64 ones for example. And chances that someone will > hacks this file out in a random subsystem when adding news ports also > is rather slim, so we'll remaing broken by default. > > That is why I want at very least: a whitelist instead of a blacklist > and some very big comments explaining what is going on here. ideally, we'd turn off this optimization entirely unless running on x86. That would be my preference. However, given the above re non-cache coherent systems, i am cautious. > And in > the mid to long term even drm really needs to learn to use the > proper APIs :( +1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/3] PM/runtime:Replace jiffies based accounting with ktime based accounting
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 à 14:16:28 (-0800), Guenter Roeck a écrit : On Fri, Dec 21, 2018 at 11:33:56AM +0100, Vincent Guittot wrote: From: Thara Gopinath This patch replaces jiffies based accounting for runtime_active_time and runtime_suspended_time with ktime base accounting. This makes the runtime debug counters inline with genpd and other pm subsytems which uses ktime based accounting. timekeeping is initialized before pm_runtime_init() so ktime_get() will be ready before first call. In fact, timekeeping_init() is called early in start_kernel() which is way before driver_init() (and that's when devices can start to be initialized) called from rest_init() via kernel_init_freeable() and do_basic_setup(). This is not (always) correct. My qemu "collie" boot test fails with this patch applied. Reverting the patch fixes the problem. Bisect log attached. Can you try the patch below ? ktime_get_mono_fast_ns() has the advantage of being init with dummy clock so it can be used at early_init. Another possibility would be delay the init of the gpiochip Well, right. Initializing devices before timekeeping doesn't feel particularly robust from the design perspective. How exactly does that happen? With an added 'initialized' flag and backtrace into the timekeeping code, with the change suggested earlier applied: [ cut here ] WARNING: CPU: 0 PID: 0 at kernel/time/timekeeping.c:453 ktime_get_mono_fast_ns+0x114/0x12c Timekeeping not initialized CPU: 0 PID: 0 Comm: swapper Not tainted 5.0.0-rc2-next-20190117-dirty #2 Hardware name: Sharp-Collie Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r7:0009 r6: r5:c065ba90 r4:c06d3e54 [] (show_stack) from [] (dump_stack+0x20/0x28) [] (dump_stack) from [] (__warn+0xcc/0xf4) [] (__warn) from [] (warn_slowpath_fmt+0x4c/0x6c) r8:df407b08 r7: r6:c0c01550 r5:c065bad8 r4:c06dd028 [] (warn_slowpath_fmt) from [] (ktime_get_mono_fast_ns+0x114/0x12c) r3: r2:c065bad8 r5: r4:df407b08 [] (ktime_get_mono_fast_ns) from [] (pm_runtime_init+0x38/0xb8) r9:c06c9a5c r8:df407b08 r7: r6:c0c01550 r5: r4:df407b08 [] (pm_runtime_init) from [] (device_initialize+0xb0/0xec) r7: r6:c0c01550 r5: r4:df407b08 [] (device_initialize) from [] (gpiochip_add_data_with_key+0x9c/0x884) r7: r6:c06fca34 r5: r4: [] (gpiochip_add_data_with_key) from [] (sa1100_init_gpio+0x40/0x98) r10:dfffcd60 r9:c06c9a5c r8:c06dd020 r7:c06dd028 r6: r5: r4:c06fca34 [] (sa1100_init_gpio) from [] (sa1100_init_irq+0x2c/0x3c) r7:c06dd028 r6: r5:c0713300 r4:c06e1070 [] (sa1100_init_irq) from [] (init_IRQ+0x20/0x28) r5:c0713300 r4: [] (init_IRQ) from [] (start_kernel+0x254/0x4cc) [] (start_kernel) from [<>] ( (null)) r10:717f r9:6901b119 r8:c100 r7:0092 r6:313d r5:0053 r4:c06a7330 ---[ end trace 91e1bd00dd7cce32 ]--- Does it means that only the pm_runtime_init is done before timekeeping_init() but no update_pm_runtime_accounting() ? In this case, we can keep using ktimeçget in update_pm_runtime_accounting() and find a solution to deal with early_call of pm_runtime_init() For this platform that is correct. I can't answer for the generic case. Guenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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-mapping implementations! > > > > > > > Is that documented anywhere? > > 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 'export' things in a way that this header doesn't? > > > And even if something like this was valid to do, it would have to be > > > a core function with an arch hook, and not hidden in a random driver. > > > > Why would it not be valid to do? Is it wrong for a driver to be aware > > of whether a device is cache coherent or not? > > > > And in case it isn't, do you have an alternative suggestion on how to > > fix this mess? > > For the write combine mappings we need a proper core API how instances > can advertise the support. One thing I want to do fairly soon is > error checking of the attrs argument to dma_alloc_attrs - so if you > pass in something unsupported it will give you back an error. > That sounds useful. > It seems that isn't quite enough for the drm use case, so we might > also need a way to query these features, but that really has to go > through the usual dma layer abstraction as well and not hacked together > in a driver based on an eduacted guestimate. As far as I can tell, these drivers allocate DMA'able memory [in ttm_tt_populate()] and subsequently create their own CPU mappings for it, assuming that a) the default is cache coherent, so vmap()ing those pages with cacheable attributes works, and b) telling the GPU to use NoSnoop attributes makes the accesses it performs coherent with non-cacheable CPU mappings of those physical pages Since the latter is not true for many arm64 systems, I need this patch to get a working system. So how do you propose we proceed to get this fixed? Does it have to wait for this proper core API plus followup changes for DRM? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
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 :-)
> >
> > On Tue, Jan 15, 2019 at 12:40:16PM -0600, Andrew F. Davis wrote:
> >> On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> >>> On 1/15/19 11:45 AM, Liam Mark wrote:
> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>
> > On 1/14/19 11:13 AM, Liam Mark wrote:
> >> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> >>
> >>> Buffers may not be mapped from the CPU so skip cache maintenance
> >>> here.
> >>> Accesses from the CPU to a cached heap should be bracketed with
> >>> {begin,end}_cpu_access calls so maintenance should not be needed
> >>> anyway.
> >>>
> >>> Signed-off-by: Andrew F. Davis
> >>> ---
> >>> drivers/staging/android/ion/ion.c | 7 ---
> >>> 1 file changed, 4 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/staging/android/ion/ion.c
> >>> b/drivers/staging/android/ion/ion.c
> >>> index 14e48f6eb734..09cb5a8e2b09 100644
> >>> --- a/drivers/staging/android/ion/ion.c
> >>> +++ b/drivers/staging/android/ion/ion.c
> >>> @@ -261,8 +261,8 @@ static struct sg_table
> >>> *ion_map_dma_buf(struct dma_buf_attachment *attachment,
> >>>
> >>> table = a->table;
> >>>
> >>> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> >>> - direction))
> >>> + if (!dma_map_sg_attrs(attachment->dev, table->sgl, table->nents,
> >>> + direction, DMA_ATTR_SKIP_CPU_SYNC))
> >>
> >> Unfortunately I don't think you can do this for a couple reasons.
> >> You can't rely on {begin,end}_cpu_access calls to do cache
> >> maintenance.
> >> If the calls to {begin,end}_cpu_access were made before the call
> >> to
> >> dma_buf_attach then there won't have been a device attached so the
> >> calls
> >> to {begin,end}_cpu_access won't have done any cache maintenance.
> >>
> >
> > That should be okay though, if you have no attachments (or all
> > attachments are IO-coherent) then there is no need for cache
> > maintenance. Unless you mean a sequence where a non-io-coherent
> > device
> > is attached later after data has already been written. Does that
> > sequence need supporting?
>
> Yes, but also I think there are cases where CPU access can happen
> before
> in Android, but I will focus on later for now.
>
> > DMA-BUF doesn't have to allocate the backing
> > memory until map_dma_buf() time, and that should only happen after
> > all
> > the devices have attached so it can know where to put the buffer.
> > So we
> > shouldn't expect any CPU access to buffers before all the devices
> > are
> > attached and mapped, right?
> >
>
> Here is an example where CPU access can happen later in Android.
>
> Camera device records video -> software post processing -> video
> device
> (who does compression of raw data) and writes to a file
>
> In this example assume the buffer is cached and the devices are not
> IO-coherent (quite common).
>
> >>>
> >>> This is the start of the problem, having cached mappings of memory
> >>> that
> >>> is also being accessed non-coherently is going to cause issues one way
> >>> or another. On top of the speculative cache fills that have to be
> >>> constantly fought back against with CMOs like below; some coherent
> >>> interconnects behave badly when you mix coherent and non-coherent
> >>> access
> >>> (snoop filters get messed up).
> >>>
> >>> The solution is to either always have the addresses marked
> >>> non-coherent
> >>> (like device memory, no-map carveouts), or if you really want to use
> >>> regular system memory allocated at runtime, then all cached mappings
> >>> of
> >>> it need to be dropped, even the kernel logical address (area as
> >>> painful
> >>> as that would be).
> >
> > Ouch :-( I wasn't aware about these potential interconnect issues. How
> > "real" is that? It seems that we aren't really hitting that today on
> > real devices.
> >
>
> Sadly there is at least one real device like this now (TI AM654). We
> spent some time working with the ARM interconnect spec designers to see
> if this was allowed behavior, final
Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed
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, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote: > > > > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a): > > > > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote: > > > > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes napisal(a): > > > > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec wrote: > > > > > > > > > Currently MP clocks don't consider adjusting parent rate > > > > > > > > > even if > > > > > > > > > they > > > > > > > > > are allowed to do so. Such behaviour considerably lowers > > > > > > > > > amount of > > > > > > > > > possible rates, which is very inconvenient when such clock > > > > > > > > > is used > > > > > > > > > for > > > > > > > > > pixel clock, for example. > > > > > > > > > > > > > > > > > > In order to improve the situation, adjusting parent rate is > > > > > > > > > considered > > > > > > > > > when allowed. > > > > > > > > > > > > > > > > > > This code is inspired by clk_divider_bestdiv() function, > > > > > > > > > which > > > > > > > > > does > > > > > > > > > basically the same thing for different clock type. > > > > > > > > > > > > > > > > This patch seems to break the eMMC support on > > > > > > > > Olinuxino-Lime2-eMMC > > > > > > > > boards: > > > > > > > > > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly > > > > > > > > filesystem > > > > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during > > > > > > > > recovery > > > > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command > > > > > > > > sunxi-mmc 1c11000.mmc: send stop command failed > > > > > > > > > > > > > > I'm not familiar with A20. What is interesting is that emmc > > > > > > > clocks > > > > > > > don't > > > > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any > > > > > > > difference. > > > > > > > > > > > > > > Can you post content of clk_summary with and without this patch? > > > > > > > > > > > > In both cases I booted from FEL with rootfs on sdcard and tried to > > > > > > mount > > > > > > partition from eMMC to /mnt. With your patch, last step it fails. > > > > > > > > > > > > pre-patch working: > > > > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2 > > > > > > is > > > > > > off?) > > > > > > > > > > > > post-patch not working: > > > > > > pll-periph[600MHz] -> mmc2[500Mhz], (ahb-mmc2 is enabled) > > > > > > > > > > > > Also, attached the logs. > > > > > > > > > > Thanks. Just one more request. Can you enable debug messages in mmc > > > > > driver? > > > > > I'm interested in output of this line: > > > > > > > > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n", > > > > > > > > > > clock, rate); > > > > > > > > 1c11000 is eMMC: > > > > [snip] > > > > [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded > > > > 40 > > > > [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded > > > > 5200 [2.203340] sunxi-mmc 1c11000.mmc: setting clk to > > > > 5200, > > > > rounded 5200 [2.211412] sunxi-mmc 1c11000.mmc: setting clk to > > > > 5200, rounded 5200 [4.967865] sunxi-mmc 1c11000.mmc: > > > > setting > > > > clk to 5200, rounded 5200 [8.755345] sunxi-mmc > > > > 1c11000.mmc: > > > > setting clk to 5200, rounded 5200 [9.082510] sunxi-mmc > > > > 1c11000.mmc: setting clk to 5200, rounded 5200 > > > > > > > > Here I tried to mount partition from eMMC... > > > > > > > > [ 72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded > > > > 5200 [ 72.269629] sunxi-mmc 1c11000.mmc: data error, sending > > > > stop > > > > command [ 73.268999] sunxi-mmc 1c11000.mmc: send stop command failed > > > > [/snip] > > > > > > > > And clock tree: > > > > [snip] > > > > pll-periph-base330 12 > > > > 0 > > > > > > > > 0 5 pll-periph
Re: [Xen-devel] [PATCH v2] drm/xen-front: Make shmem backed display buffer coherent
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 getting more and more confusing. Well, I don't really do DMA here, but instead the buffers in question are shared with other Xen domain, so effectively it could be thought of some sort of DMA here, where the "device" is that remote domain. If the buffers are not flushed then the remote part sees some inconsistency which in my case results in artifacts on screen while displaying the buffers. When buffers are allocated via DMA API then there are no artifacts; if buffers are allocated with shmem + DMA mapping then there are no artifacts as well. The only offending use-case is when I use shmem backed buffers, but do not flush them The right answer would be to implement cache maintainance hooks for this case in the Xen arch code. These would basically look the same as the low-level cache maintainance used by the DMA ops, but without going through the DMA mapping layer, in fact they should probably reuse the same low-level assembly routines. I don't think this is the first usage of such Xen buffer sharing, so what do the other users do? I'll have to get even deeper into it. Initially I looked at the code, but didn't find anything useful. Or maybe I have just overlooked obvious things there From Xen on Arm ABI: "All memory which is shared with other entities in the system (including the hypervisor and other guests) must reside in memory which is mapped as Normal Inner Write-Back Outer Write-Back Inner-Shareable. This applies to: - hypercall arguments passed via a pointer to guest memory. - memory shared via the grant table mechanism (including PV I/O rings etc). - memory shared with the hypervisor (struct shared_info, struct vcpu_info, the grant table, etc). " So you should not need any cache maintenance here. Can you provide more details on the memory attribute you use for memory shared in both the backend and frontend? It takes quite some time to collect this (because many components are involved in the use-case), but for now the pages in the guest domain are: !PTE_RDONLY + PTE_PXN + PTE_SHARED + PTE_AF + PTE_UXN + PTE_ATTRINDX(MT_NORMAL) So that's the attribute for the page mapped in the frontend, right? How about the backend side? Also, could that page be handed to the graphic card correctly? If so, is your graphic card coherent? If one of your components is mapping with non-cacheable attributes then you are already not following the Xen Arm ABI. In that case, we would need to discuss how to extend the ABI. Cheers, -- Julien Grall ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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 'export' things in a way > > that this header doesn't? > > Well, I'll add comments to make it more obvious.. > > > As far as I can tell, these drivers allocate DMA'able memory [in > > ttm_tt_populate()] and subsequently create their own CPU mappings for > > it, assuming that > > a) the default is cache coherent, so vmap()ing those pages with > > cacheable attributes works, and > > Yikes. vmaping with different attributes is generally prone to > create problems on a lot of architectures. > Indeed. But if your starting point is the assumption that DMA is always cache coherent, those vmap() attributes are never different. > > b) telling the GPU to use NoSnoop attributes makes the accesses it > > performs coherent with non-cacheable CPU mappings of those physical > > pages > > > > Since the latter is not true for many arm64 systems, I need this patch > > to get a working system. > > Do we know that this actually works anywhere but x86? > In theory, it could work on arm64 systems with stage2-only SMMUs and correctly configured PCIe RCs that set the right AMBA attributes for inbound transactions with the NoSnoop attributes set. Unfortunately, it seems that the current SMMU ARM code will clobber those AMBA attributes when it uses stage1 mappings, since it forces the memory attributes to WBWA for cache coherent devices. So, as I pointed out in the commit log, the main difference between x86 and other arches it that it can easily tolerate when NoSnoop is non-functional. > In general I would call these above sequence rather bogus and would > prefer we could get rid of such antipatterns in the kernel and just use > dma_alloc_attrs with DMA_ATTR_WRITECOMBINE if we want writecombine > semantics. > Agreed. > 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 actually work. And document that fact > in big fat comments. Well, as I mentioned in my commit log as well, if we default to off unless CONFIG_X86, we may break working setups on MIPS and Power where the device is in fact non-cache coherent, and relies on this 'optimization' to get things working. The same could be true for non-coherent ARM systems, hence my approach to disable this hack for cache coherent devices on non-X86 only. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
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 is an API design which the user is more likely to get wrong than > right and thus does not pass the smell test. > With the previous version of ION Android ION clients were successfully managing all their cache maintenance. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/sun4i: hdmi: Fix usage of TMDS clock
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 for each EDID probe, causing spurious failures
for certain HDMI/DVI screens.
Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support")
Signed-off-by: Priit Laes
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 061d2e0d9011..25f4d676fd82 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -92,6 +92,8 @@ static void sun4i_hdmi_disable(struct drm_encoder *encoder)
val = readl(hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
val &= ~SUN4I_HDMI_VID_CTRL_ENABLE;
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
+
+ clk_disable_unprepare(hdmi->tmds_clk);
}
static void sun4i_hdmi_enable(struct drm_encoder *encoder)
@@ -112,6 +114,8 @@ static void sun4i_hdmi_enable(struct drm_encoder *encoder)
val |= SUN4I_HDMI_VID_CTRL_HDMI_MODE;
writel(val, hdmi->base + SUN4I_HDMI_VID_CTRL_REG);
+
+ clk_prepare_enable(hdmi->tmds_clk);
}
static void sun4i_hdmi_mode_set(struct drm_encoder *encoder,
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
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, 2019 at 10:10:53AM +, Priit Laes wrote: > > > > > > > > > > It doesn't look related to the clock rate itself, since it > > > > > > > > > > doesn't > > > > > > > > > > change between the two cases. However, in one case the DDC > > > > > > > > > > clock is > > > > > > > > > > enabled and in the other it's disabled. > > > > > > > > > > > > > > > > > > > > Was it taken at the same time? Maybe you can try with that > > > > > > > > > > patch? > > > > > > > > > > http://code.bulix.org/z7jmkm-555344?raw > > > > > > > > > > > > > > > > > > Thanks, after doing ~50+ boots I haven't seen a single > > > > > > > > > failure. > > > > > > > > > > > > > > > > > > Previously I had following failure cases which are now both > > > > > > > > > fixed: > > > > > > > > > > > > > > > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots > > > > > > > > > failed. > > > > > > > > > b) u--boot with hdmi enabled switching to simplefb and then > > > > > > > > > switching > > > > > > > > > to kms, where previously all boots ended up with garbled > > > > > > > > > screen. > > > > > > > > > > > > > > > > So it's not really a fix, but it really looks like the clock > > > > > > > > is not > > > > > > > > enabled when it should. > > > > > > > > > > > > > > > > Can you describe your test scenario a bit more? What are you > > > > > > > > doing > > > > > > > > exactly, just booting? When do you start using the display? > > > > > > > > When did > > > > > > > > you capture the debugfs output that you pasted? > > > > > > > > > > > > > > Display is already connected via HDMI to the board. I don't > > > > > > > really > > > > > > > remove it, I just boot the device and let it start Xorg. > > > > > > > Meanwhile I just ssh into the device and capture debugfs output. > > > > > > > See my 3 testing scenarios below. > > > > > > > > > > > > > > Kernel also includes one extra patch to fall back to DDC, in > > > > > > > case HPD > > > > > > > fails. Mostly the same I already submitted last November [1]. > > > > > > > > > > > > Do you have the same issue without that patch? > > > > > > > > > > Can't really test this display without this patch and I do not have > > > > > other > > > > > HDMI/DVI screens. And this issue does not happen with other HDMI > > > > > displays > > > > > that I have here. > > > > > > > > Can't you just force the monitor to be reported as present? It's not > > > > great and we don't want to merge it, but that would allow you to test > > > > that setup without too many interferences. > > > > > > Baseline is clean u-boot / linux. U-boot does not detect/enable display. > > > > > > 1) Booting Linux with drm.debug=0xe > > > > > > * Linux does not detect/enable display > > > > > > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > > > * Linux detects display, but display is garbled, and proper edid data is > > > detected: > > > > > > [snip] > > > pll-video1 000 32700 > > > 0 0 5> > > > >pll-video1-2x 000 65400 > > >0 0 5> > > > > hdmi-tmds00025153846 > > > 0 0 5> > > > > hdmi-ddc 000 89835 > > > 0 0 5> > > > > [/snip] > > > > > > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > And also one extra patch for Linux where HDMI DDC clock marked as > > > critical > > > > > > Linux detects and initializes display properly: > > > [snip] > > > pll-video1 110 32700 > > > 0 0 5> > > > >pll-video1-2x 110 65400 > > >0 0 5> > > > > hdmi-tmds11025153846 > > > 0 0 5> > > > > hdmi-ddc 110 89835 > > > 0 0 5> > > > > [/snip] > > > > I guess you'll need to track down when the hdmi-tmds and hdmi-ddc are > > enabled and disabled, and if it makes sense :/ > > OK, figured out the cause. > > Apparently, for each ddc poll we enable ddc clock which is a child of TMDS > clock. After transfer is done, we disable the clock and this also tears down > the parent because its only user has gone missing.. :( > > > So basically, patch below also works, but I guess we should override > the sun4i_tmds_ops.disable to properly account for tmds clock use. > As far as I can see, nobody called clk_prepare_enable() on tmds clock. I had similar issue with TMDS clock for H3, since I based code
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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-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 where we 100% > >> positively know that they actually work. And document that fact > >> in big fat comments. > > > > Well, as I mentioned in my commit log as well, if we default to off > > unless CONFIG_X86, we may break working setups on MIPS and Power where > > the device is in fact non-cache coherent, and relies on this > > 'optimization' to get things working. > > FWIW, the amdgpu driver doesn't rely on non-snooped transfers for > correct basic operation (the scenario Christian brought up is a very > specialized use-case), so that shouldn't be an issue. > > >>> > >>> The point is that this is only true for x86. > >>> > >>> On other architectures, the use of non-cached mappings on the CPU side > >>> means that you /do/ rely on non-snooped transfers, since if those > >>> transfers turn out not to snoop inadvertently, the accesses are > >>> incoherent with the CPU's view of memory. > >> > >> The driver generally only uses non-cached mappings if > >> drm_arch/device_can_wc_memory returns true. > >> > > > > Indeed. And so we should take care to only return 'true' from that > > function if it is guaranteed that non-cached CPU mappings are coherent > > with the mappings used by the GPU, either because that is always the > > case (like on x86), or because we know that the platform in question > > implements NoSnoop correctly throughout the interconnect. > > > > What seems to be complicating matters is that in some cases, the > > device is non-cache coherent to begin with, so regardless of whether > > the NoSnoop attribute is used or not, those accesses will not snoop in > > the caches and be coherent with the non-cached mappings used by the > > CPU. So if we restrict this optimization [on non-X86] to platforms > > that are known to implement NoSnoop correctly, we may break platforms > > that are implicitly NoSnoop all the time. > > Since the driver generally doesn't rely on non-snooped accesses for > correctness, that couldn't "break" anything that hasn't always been broken. > Again, that is only true on x86. On other architectures, DMA writes from the device may allocate in the caches, and be invisible to the CPU when it uses non-cached mappings. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/14] staging: android: ion: Do not sync CPU cache on map/unmap
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 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/15/19 1:05 PM, Laura Abbott wrote:
> >>> On 1/15/19 10:38 AM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark wrote:
> > On Tue, 15 Jan 2019, Andrew F. Davis wrote:
> >
> >> On 1/14/19 11:13 AM, Liam Mark wrote:
> >>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> >>>
> Buffers may not be mapped from the CPU so skip cache maintenance
> here.
> Accesses from the CPU to a cached heap should be bracketed with
> {begin,end}_cpu_access calls so maintenance should not be needed
> anyway.
>
> Signed-off-by: Andrew F. Davis
> ---
> drivers/staging/android/ion/ion.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 14e48f6eb734..09cb5a8e2b09 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -261,8 +261,8 @@ static struct sg_table
> *ion_map_dma_buf(struct
> dma_buf_attachment *attachment,
> table = a->table;
> - if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
> - direction))
> + if (!dma_map_sg_attrs(attachment->dev, table->sgl,
> table->nents,
> + direction, DMA_ATTR_SKIP_CPU_SYNC))
> >>>
> >>> Unfortunately I don't think you can do this for a couple reasons.
> >>> You can't rely on {begin,end}_cpu_access calls to do cache
> >>> maintenance.
> >>> If the calls to {begin,end}_cpu_access were made before the call
> >>> to
> >>> dma_buf_attach then there won't have been a device attached so the
> >>> calls
> >>> to {begin,end}_cpu_access won't have done any cache maintenance.
> >>>
> >>
> >> That should be okay though, if you have no attachments (or all
> >> attachments are IO-coherent) then there is no need for cache
> >> maintenance. Unless you mean a sequence where a non-io-coherent
> >> device
> >> is attached later after data has already been written. Does that
> >> sequence need supporting?
> >
> > Yes, but also I think there are cases where CPU access can happen
> > before
> > in Android, but I will focus on later for now.
> >
> >> DMA-BUF doesn't have to allocate the backing
> >> memory until map_dma_buf() time, and that should only happen after
> >> all
> >> the devices have attached so it can know where to put the buffer.
> >> So we
> >> shouldn't expect any CPU access to buffers before all the devices
> >> are
> >> attached and mapped, right?
> >>
> >
> > Here is an example where CPU access can happen later in Android.
> >
> > Camera device records video -> software post processing -> video
> > device
> > (who does compression of raw data) and writes to a file
> >
> > In this example assume the buffer is cached and the devices are not
> > IO-coherent (quite common).
> >
>
> This is the start of the problem, having cached mappings of memory
> that
> is also being accessed non-coherently is going to cause issues one
> way
> or another. On top of the speculative cache fills that have to be
> constantly fought back against with CMOs like below; some coherent
> interconnects behave badly when you mix coherent and non-coherent
> access
> (snoop filters get messed up).
>
> The solution is to either always have the addresses marked
> non-coherent
> (like device memory, no-map carveouts), or if you really want to use
> regular system memory allocated at runtime, then all cached mappings
> of
> it need to be dropped, even the kernel logical address (area as
> painful
> as that would be).
>
> >>>
> >>> I agree it's broken, hence my desire to remove it :)
> >>>
> >>> The other problem is that uncached buffers are being used for
> >>> performance reason so anything that would involve getting
> >>> rid of the logical address would probably negate an
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
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 > > > might get translated to the DMA API flags, which are not error checked, > > > not very well documented and way to easy to get wrong. > > > > > > > I'm not sure having flags in dma-buf really solves anything > > given drivers can use the attributes directly with dma_map > > anyway, which is what we're looking to do. The intention > > is for the driver creating the dma_buf attachment to have > > the knowledge of which flags to use. > > Well, there are very few flags that you can simply use for all calls of > dma_map*. And given how badly these flags are defined I just don't want > people to add more places where they indirectly use these flags, as > it will be more than enough work to clean up the current mess. > > What flag(s) do you want to pass this way, btw? Maybe that is where > the problem is. > 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_unmap_attachment. In ION the buffers aren't usually accessed from the CPU so this allows clients to often avoid doing unnecessary cache maintenance. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdkfd: Fix if preprocessor statement above kfd_fill_iolink_info_for_cpu
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 as I forgot to add the lists...
drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
index 5d85ff341385..2e7c44955f43 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
@@ -863,7 +863,7 @@ static int kfd_fill_mem_info_for_cpu(int numa_node_id, int
*avail_size,
return 0;
}
-#if CONFIG_X86_64
+#ifdef CONFIG_X86_64
static int kfd_fill_iolink_info_for_cpu(int numa_node_id, int *avail_size,
uint32_t *num_entries,
struct crat_subtype_iolink *sub_type_hdr)
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] dt-bindings: display: armada: Add display subsystem binding
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
> > ---
> > .../display/armada/marvell-armada-drm.txt | 24 +++
> > 1 file changed, 24 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > index de4cca9432c8..3dbfa8047f0b 100644
> > ---
> > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > +++
> > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > @@ -1,3 +1,27 @@
> > +Marvell Armada DRM master device
> > +
> > +
> > +The Marvell Armada DRM master device is a virtual device needed to list all
> > +nodes that comprise the graphics subsystem.
> > +
> > +Required properties:
> > +
> > + - compatible: value should be "marvell,dove-display-subsystem",
> > + "marvell,armada-display-subsystem"
> > + - ports: a list of phandles pointing to display interface ports of CRTC
> > + devices
> > + - memory-region: phandle to a node describing memory to be used for the
> > + framebuffer
> > +
> > +Example:
> > +
> > + display-subsystem {
> > + compatible = "marvell,dove-display-subsystem",
> > +"marvell,armada-display-subsystem";
> > + memory-region = <&display_reserved>;
> > + ports = <&lcd0_port>;
>
> If there is only one device, you don't need this virtual node.
By "one device" you mean one LCD controller (CRTC)?
I suppose in the (single CRTC) example case, the display-subsystem node
used to associate it with the memory region reserved for allocating the
frame buffers from. Could that be done differently?
Also, if the node is indeed made optional, then it's going to
complicate things on the DRM side. Currently the driver that binds to
the node creates the DRM device once it sees all the components
connected to the ports appear. If we loose it, then the LCD controller
driver would somehow need to find out that it's alone and create the
DRM device itself.
Thank you
Lubo
>
>
> > + };
> > +
> > Marvell Armada LCD controller
> > =
> >
> > --
> > 2.20.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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., 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: > >>> > 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 actually work. And document that fact > in big fat comments. > >>> > >>> Well, as I mentioned in my commit log as well, if we default to off > >>> unless CONFIG_X86, we may break working setups on MIPS and Power where > >>> the device is in fact non-cache coherent, and relies on this > >>> 'optimization' to get things working. > >> > >> FWIW, the amdgpu driver doesn't rely on non-snooped transfers for > >> correct basic operation (the scenario Christian brought up is a very > >> specialized use-case), so that shouldn't be an issue. > > > > The point is that this is only true for x86. > > > > On other architectures, the use of non-cached mappings on the CPU side > > means that you /do/ rely on non-snooped transfers, since if those > > transfers turn out not to snoop inadvertently, the accesses are > > incoherent with the CPU's view of memory. > > The driver generally only uses non-cached mappings if > drm_arch/device_can_wc_memory returns true. > >>> > >>> Indeed. And so we should take care to only return 'true' from that > >>> function if it is guaranteed that non-cached CPU mappings are coherent > >>> with the mappings used by the GPU, either because that is always the > >>> case (like on x86), or because we know that the platform in question > >>> implements NoSnoop correctly throughout the interconnect. > >>> > >>> What seems to be complicating matters is that in some cases, the > >>> device is non-cache coherent to begin with, so regardless of whether > >>> the NoSnoop attribute is used or not, those accesses will not snoop in > >>> the caches and be coherent with the non-cached mappings used by the > >>> CPU. So if we restrict this optimization [on non-X86] to platforms > >>> that are known to implement NoSnoop correctly, we may break platforms > >>> that are implicitly NoSnoop all the time. > >> > >> Since the driver generally doesn't rely on non-snooped accesses for > >> correctness, that couldn't "break" anything that hasn't always been broken. > > > > Again, that is only true on x86. > > > > On other architectures, DMA writes from the device may allocate in the > > caches, and be invisible to the CPU when it uses non-cached mappings. > > Let me try one last time: > > If drm_arch_can_wc_memory returns false, the driver falls back to the > normal mode of operation, using a cacheable CPU mapping and snooped GPU > transfers, even if userspace asks (as a performance optimization) for a > write-combined CPU mapping and non-snooped GPU transfers via > AMDGPU_GEM_CREATE_CPU_GTT_USWC. Another question: when userspace requests for such a mapping to be created, does this involve pages that are mapped cacheable into the userland process? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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., 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: > >>> > 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 actually work. And document that fact > in big fat comments. > >>> > >>> Well, as I mentioned in my commit log as well, if we default to off > >>> unless CONFIG_X86, we may break working setups on MIPS and Power where > >>> the device is in fact non-cache coherent, and relies on this > >>> 'optimization' to get things working. > >> > >> FWIW, the amdgpu driver doesn't rely on non-snooped transfers for > >> correct basic operation (the scenario Christian brought up is a very > >> specialized use-case), so that shouldn't be an issue. > > > > The point is that this is only true for x86. > > > > On other architectures, the use of non-cached mappings on the CPU side > > means that you /do/ rely on non-snooped transfers, since if those > > transfers turn out not to snoop inadvertently, the accesses are > > incoherent with the CPU's view of memory. > > The driver generally only uses non-cached mappings if > drm_arch/device_can_wc_memory returns true. > >>> > >>> Indeed. And so we should take care to only return 'true' from that > >>> function if it is guaranteed that non-cached CPU mappings are coherent > >>> with the mappings used by the GPU, either because that is always the > >>> case (like on x86), or because we know that the platform in question > >>> implements NoSnoop correctly throughout the interconnect. > >>> > >>> What seems to be complicating matters is that in some cases, the > >>> device is non-cache coherent to begin with, so regardless of whether > >>> the NoSnoop attribute is used or not, those accesses will not snoop in > >>> the caches and be coherent with the non-cached mappings used by the > >>> CPU. So if we restrict this optimization [on non-X86] to platforms > >>> that are known to implement NoSnoop correctly, we may break platforms > >>> that are implicitly NoSnoop all the time. > >> > >> Since the driver generally doesn't rely on non-snooped accesses for > >> correctness, that couldn't "break" anything that hasn't always been broken. > > > > Again, that is only true on x86. > > > > On other architectures, DMA writes from the device may allocate in the > > caches, and be invisible to the CPU when it uses non-cached mappings. > > Let me try one last time: > I could say the same :-) > If drm_arch_can_wc_memory returns false, the driver falls back to the > normal mode of operation, using a cacheable CPU mapping and snooped GPU > transfers, even if userspace asks (as a performance optimization) for a > write-combined CPU mapping and non-snooped GPU transfers via > AMDGPU_GEM_CREATE_CPU_GTT_USWC. I am not talking about the case where drm_arch_can_wc_memory() returns false. I am talking about the case where it returns true, which is currently the default for all architectures, except Power and MIPS in some cases. This mode of operation breaks my cache coherent arm64 system. (AMD Seattle) With this patch applied, everything works fine. > This normal mode of operation is also > used for the ring buffers at the heart of the driver's operation. But is it really the same mode of operation? Does it also vmap() the pages? Or does it use the DMA API to allocate the ring buffers? Because in the latter case, this will give you non-cached CPU mappings as well if the device is non-cache coherent. > If > there is a platform where this normal mode of operation doesn't work, > the driver could never have worked reliably on that platform, since > before AMDGPU_GEM_CREATE_CPU_GTT_USWC or drm_arch_can_wc_memory even > existed. > As I said, I am talking about the case where drm_arch_can_wc_memory() returns true on a cache coherent system. This relies on NoSnoop being implemented correctly in the platform, or a CPU architecture that snoops the caches when doing uncached memory accesses (such as x86) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
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 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 > >> might get translated to the DMA API flags, which are not error checked, > >> not very well documented and way to easy to get wrong. > >> > > > > I'm not sure having flags in dma-buf really solves anything > > given drivers can use the attributes directly with dma_map > > anyway, which is what we're looking to do. The intention > > is for the driver creating the dma_buf attachment to have > > the knowledge of which flags to use. > > Well, there are very few flags that you can simply use for all calls of > dma_map*. And given how badly these flags are defined I just don't want > people to add more places where they indirectly use these flags, as > it will be more than enough work to clean up the current mess. > > What flag(s) do you want to pass this way, btw? Maybe that is where > the problem is. > > >>> > >>> 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_unmap_attachment. In > >>> ION the buffers aren't usually accessed from the CPU so this allows > >>> clients to often avoid doing unnecessary cache maintenance. > >>> > >> > >> How can a client know that no CPU access has occurred that needs to be > >> flushed out? > >> > > > > 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). > > > > For example with the previous version of ION we left all decisions of > > whether cache maintenance was required up to the client, they would use > > the ION cache maintenance IOCTL to force cache maintenance only when it > > was required. > > In these cases almost all of the access was being done by the device and > > in the rare cases CPU access was required clients would initiate the > > required cache maintenance before and after the CPU access. > > > > I think we have different definitions of "client", I'm talking about the > DMA-BUF client (the importer), that is who can set this flag. It seems > you mean the userspace application, which has no control over this flag. > I am also talking about dma-buf clients, I am referring to both the userspace and kernel component of the client. For example our Camera ION client has both a usersapce and kernel component and they have ION buffers, which they control the access to, which may or may not be accessed by the CPU in certain uses cases. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/3] drm/msm/a6xx: Add support for an interconnect path
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 needed for performance.
>>> Later we will want to scale the bandwidth based on the frequency to
>>> also optimize for power but that will require some device tree
>>> infrastructure that does not yet exist.
>>>
>>> v5: Remove hardcoded interconnect name and just use the default
>>
>> nit: ${SUBJECT} says v3, but this is v5.
>>
>> I'll put in my usual plug for considering "patman" to help post
>> patches. Even though it lives in the u-boot git repo it's still a gem
>> for kernel work.
>>
>>
>>
>>> @@ -85,6 +89,12 @@ static void __a6xx_gmu_set_freq(struct a6xx_gmu *gmu,
>>> int index)
>>> dev_err(gmu->dev, "GMU set GPU frequency error: %d\n", ret);
>>>
>>> gmu->freq = gmu->gpu_freqs[index];
>>> +
>>> + /*
>>> +* Eventually we will want to scale the path vote with the
>>> frequency but
>>> +* for now leave it at max so that the performance is nominal.
>>> +*/
>>> + icc_set(gpu->icc_path, 0, MBps_to_icc(7216));
>>
>> You'll need to change icc_set() here to icc_set_bw() to match v13, AKA:
>>
>> - https://patchwork.kernel.org/patch/10766335/
>> - https://lkml.kernel.org/r/20190116161103.6937-2-georgi.dja...@linaro.org
>>
>>
>>> @@ -695,6 +707,9 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
>>> if (ret)
>>> goto out;
>>>
>>> + /* Set the bus quota to a reasonable value for boot */
>>> + icc_set(gpu->icc_path, 0, MBps_to_icc(3072));
>>
>> This will also need to change to icc_set_bw()
>>
>>
>>> @@ -781,6 +798,9 @@ int a6xx_gmu_stop(struct a6xx_gpu *a6xx_gpu)
>>> /* Tell RPMh to power off the GPU */
>>> a6xx_rpmh_stop(gmu);
>>>
>>> + /* Remove the bus vote */
>>> + icc_set(gpu->icc_path, 0, 0);
>>
>> This will also need to change to icc_set_bw()
>>
>>
>> I have the same questions for this series that I had in response to
>> the email ("[v5 2/3] drm/msm/dpu: Integrate interconnect API in MDSS")
>>
>>
>>
>> Copy / pasting here (with minor name changes) so folks don't have to
>> follow links / search email.
>>
>> ==
>>
>> I'm curious what the plan is for landing this series. Rob / Gerogi:
>> do you have any preference? Options I'd imagine:
>>
>> A) Wait until interconnect lands (in 5.1?) and land this through
>> msm-next in the version after (5.2?)
>>
>> B) Georgi provides an immutable branch for interconnect when his lands
>> (assuming he's landing via pull request) and that gets pulled into the
>> the relevant drm tree.
>>
>> C) Rob Acks this series and indicates that it should go in through
>> Gerogi's tree (probably only works if Georgi plans to send a pull
>> request). If we're going this route then (IIUC) we'd want to land
>> this in Gerogi's tree sooner rather than later so it can get some bake
>> time? NOTE: as per my prior reply, I believe Rob has already Acked
>> this patch.
>>
>
> I'm ok to ack and have it land via Georgi's tree, if Georgi wants to
> do that. Or otherwise, I could maybe coordinate w/ airlied to send a
> 2nd late msm-next pr including the gpu and display interconnect
> patches.
I'm fine either way. But it would be nice if both patches (this one and
the dt-bindings go together. The v6 of this patch applies cleanly to my
tree, but the next one (2/3) with the dt-bindings doesn't.
Thanks,
Georgi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/9] mm: Introduce new vm_insert_range and vm_insert_range_buggy API
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 by creating new functions and use it across
> the drivers.
>
> vm_insert_range() is the API which could be used to mapped
> kernel memory/pages in drivers which has considered vm_pgoff
>
> vm_insert_range_buggy() is the API which could be used to map
> range of kernel memory/pages in drivers which has not considered
> vm_pgoff. vm_pgoff is passed default as 0 for those drivers.
>
> We _could_ then at a later "fix" these drivers which are using
> vm_insert_range_buggy() to behave according to the normal vm_pgoff
> offsetting simply by removing the _buggy suffix on the function
> name and if that causes regressions, it gives us an easy way to revert.
>
> Signed-off-by: Souptick Joarder
> Suggested-by: Russell King
> Suggested-by: Matthew Wilcox
Any comment on these APIs ?
> ---
> include/linux/mm.h | 4 +++
> mm/memory.c| 81
> ++
> mm/nommu.c | 14 ++
> 3 files changed, 99 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5411de9..9d1dff6 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2514,6 +2514,10 @@ unsigned long change_prot_numa(struct vm_area_struct
> *vma,
> int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
> unsigned long pfn, unsigned long size, pgprot_t);
> int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page
> *);
> +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num);
> +int vm_insert_range_buggy(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num);
> vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> unsigned long pfn);
> vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long
> addr,
> diff --git a/mm/memory.c b/mm/memory.c
> index 4ad2d29..00e66df 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1520,6 +1520,87 @@ int vm_insert_page(struct vm_area_struct *vma,
> unsigned long addr,
> }
> EXPORT_SYMBOL(vm_insert_page);
>
> +/**
> + * __vm_insert_range - insert range of kernel pages into user vma
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
> + * @num: number of pages in page array
> + * @offset: user's requested vm_pgoff
> + *
> + * This allows drivers to insert range of kernel pages they've allocated
> + * into a user vma.
> + *
> + * If we fail to insert any page into the vma, the function will return
> + * immediately leaving any previously inserted pages present. Callers
> + * from the mmap handler may immediately return the error as their caller
> + * will destroy the vma, removing any successfully inserted pages. Other
> + * callers should make their own arrangements for calling unmap_region().
> + *
> + * Context: Process context.
> + * Return: 0 on success and error code otherwise.
> + */
> +static int __vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num, unsigned long offset)
> +{
> + unsigned long count = vma_pages(vma);
> + unsigned long uaddr = vma->vm_start;
> + int ret, i;
> +
> + /* Fail if the user requested offset is beyond the end of the object
> */
> + if (offset > num)
> + return -ENXIO;
> +
> + /* Fail if the user requested size exceeds available object size */
> + if (count > num - offset)
> + return -ENXIO;
> +
> + for (i = 0; i < count; i++) {
> + ret = vm_insert_page(vma, uaddr, pages[offset + i]);
> + if (ret < 0)
> + return ret;
> + uaddr += PAGE_SIZE;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * vm_insert_range - insert range of kernel pages starts with non zero offset
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
> + * @num: number of pages in page array
> + *
> + * Maps an object consisting of `num' `pages', catering for the user's
> + * requested vm_pgoff
> + *
> + * Context: Process context. Called by mmap handlers.
> + * Return: 0 on success and error code otherwise.
> + */
> +int vm_insert_range(struct vm_area_struct *vma, struct page **pages,
> + unsigned long num)
> +{
> + return __vm_insert_range(vma, pages, num, vma->vm_pgoff);
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> +/**
> + * vm_insert_range_buggy - insert range of kernel pages starts with zero
> offset
> + * @vma: user vma to map to
> + * @pages: pointer to array of source kernel pages
>
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
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_unmap_attachment. In > > ION the buffers aren't usually accessed from the CPU so this allows > > clients to often avoid doing unnecessary cache maintenance. > > This can't work. The cpu can still easily speculate into this area. Can you provide more detail on your concern here. The use case I am thinking about here is a cached buffer which is accessed by a non IO-coherent device (quite a common use case for ION). Guessing on your concern: The speculative access can be an issue if you are going to access the buffer from the CPU after the device has written to it, however if you know you aren't going to do any CPU access before the buffer is again returned to the device then I don't think the speculative access is a concern. > Moreover in general these operations should be cheap if the addresses > aren't cached. > I am thinking of use cases with cached buffers here, so CMO isn't cheap. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm: disable WC optimization for cache coherent devices on non-x86
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: > >>> > 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 actually work. And document that fact > in big fat comments. > >>> > >>> Well, as I mentioned in my commit log as well, if we default to off > >>> unless CONFIG_X86, we may break working setups on MIPS and Power where > >>> the device is in fact non-cache coherent, and relies on this > >>> 'optimization' to get things working. > >> > >> FWIW, the amdgpu driver doesn't rely on non-snooped transfers for > >> correct basic operation (the scenario Christian brought up is a very > >> specialized use-case), so that shouldn't be an issue. > >> > > > > The point is that this is only true for x86. > > > > On other architectures, the use of non-cached mappings on the CPU side > > means that you /do/ rely on non-snooped transfers, since if those > > transfers turn out not to snoop inadvertently, the accesses are > > incoherent with the CPU's view of memory. > > The driver generally only uses non-cached mappings if > drm_arch/device_can_wc_memory returns true. > Indeed. And so we should take care to only return 'true' from that function if it is guaranteed that non-cached CPU mappings are coherent with the mappings used by the GPU, either because that is always the case (like on x86), or because we know that the platform in question implements NoSnoop correctly throughout the interconnect. What seems to be complicating matters is that in some cases, the device is non-cache coherent to begin with, so regardless of whether the NoSnoop attribute is used or not, those accesses will not snoop in the caches and be coherent with the non-cached mappings used by the CPU. So if we restrict this optimization [on non-X86] to platforms that are known to implement NoSnoop correctly, we may break platforms that are implicitly NoSnoop all the time. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes
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 are safe? > > I'd much rather have explicit, well documented dma-buf flags that > might get translated to the DMA API flags, which are not error checked, > not very well documented and way to easy to get wrong. > > >>> > >>> I'm not sure having flags in dma-buf really solves anything > >>> given drivers can use the attributes directly with dma_map > >>> anyway, which is what we're looking to do. The intention > >>> is for the driver creating the dma_buf attachment to have > >>> the knowledge of which flags to use. > >> > >> Well, there are very few flags that you can simply use for all calls of > >> dma_map*. And given how badly these flags are defined I just don't want > >> people to add more places where they indirectly use these flags, as > >> it will be more than enough work to clean up the current mess. > >> > >> What flag(s) do you want to pass this way, btw? Maybe that is where > >> the problem is. > >> > > > > 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_unmap_attachment. In > > ION the buffers aren't usually accessed from the CPU so this allows > > clients to often avoid doing unnecessary cache maintenance. > > > > How can a client know that no CPU access has occurred that needs to be > flushed out? > 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). For example with the previous version of ION we left all decisions of whether cache maintenance was required up to the client, they would use the ION cache maintenance IOCTL to force cache maintenance only when it was required. In these cases almost all of the access was being done by the device and in the rare cases CPU access was required clients would initiate the required cache maintenance before and after the CPU access. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: HDMI/DVI spurious failure
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 to the clock rate itself, since it > > > > > > > > > doesn't > > > > > > > > > change between the two cases. However, in one case the DDC > > > > > > > > > clock is > > > > > > > > > enabled and in the other it's disabled. > > > > > > > > > > > > > > > > > > Was it taken at the same time? Maybe you can try with that > > > > > > > > > patch? > > > > > > > > > http://code.bulix.org/z7jmkm-555344?raw > > > > > > > > > > > > > > > > Thanks, after doing ~50+ boots I haven't seen a single failure. > > > > > > > > > > > > > > > > Previously I had following failure cases which are now both > > > > > > > > fixed: > > > > > > > > > > > > > > > > a) Linux without u-boot HDMI, where one in every 6-7 boots > > > > > > > > failed. > > > > > > > > b) u--boot with hdmi enabled switching to simplefb and then > > > > > > > > switching > > > > > > > > to kms, where previously all boots ended up with garbled screen. > > > > > > > > > > > > > > So it's not really a fix, but it really looks like the clock is > > > > > > > not > > > > > > > enabled when it should. > > > > > > > > > > > > > > Can you describe your test scenario a bit more? What are you doing > > > > > > > exactly, just booting? When do you start using the display? When > > > > > > > did > > > > > > > you capture the debugfs output that you pasted? > > > > > > > > > > > > Display is already connected via HDMI to the board. I don't really > > > > > > remove it, I just boot the device and let it start Xorg. > > > > > > Meanwhile I just ssh into the device and capture debugfs output. > > > > > > See my 3 testing scenarios below. > > > > > > > > > > > > Kernel also includes one extra patch to fall back to DDC, in case > > > > > > HPD > > > > > > fails. Mostly the same I already submitted last November [1]. > > > > > > > > > > Do you have the same issue without that patch? > > > > > > > > Can't really test this display without this patch and I do not have > > > > other > > > > HDMI/DVI screens. And this issue does not happen with other HDMI > > > > displays > > > > that I have here. > > > > > > Can't you just force the monitor to be reported as present? It's not > > > great and we don't want to merge it, but that would allow you to test > > > that setup without too many interferences. > > > > Baseline is clean u-boot / linux. U-boot does not detect/enable display. > > > > 1) Booting Linux with drm.debug=0xe > > > > * Linux does not detect/enable display > > > > 2) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > > > * Linux detects display, but display is garbled, and proper edid data is > > detected: > > > > [snip] > > pll-video1 000 32700 0 > > 0 5 > >pll-video1-2x 000 65400 0 > > 0 5 > > hdmi-tmds00025153846 0 > > 0 5 > > hdmi-ddc 000 89835 0 > > 0 5 > > [/snip] > > > > 3) Booting with drm.debug=0xe video=HDMI-A-1:640x480@60e > > And also one extra patch for Linux where HDMI DDC clock marked as critical > > > > Linux detects and initializes display properly: > > [snip] > > pll-video1 110 32700 0 > > 0 5 > >pll-video1-2x 110 65400 0 > > 0 5 > > hdmi-tmds11025153846 0 > > 0 5 > > hdmi-ddc 110 89835 0 > > 0 5 > > [/snip] > > I guess you'll need to track down when the hdmi-tmds and hdmi-ddc are > enabled and disabled, and if it makes sense :/ OK, figured out the cause. Apparently, for each ddc poll we enable ddc clock which is a child of TMDS clock. After transfer is done, we disable the clock and this also tears down the parent because its only user has gone missing.. :( So basically, patch below also works, but I guess we should override the sun4i_tmds_ops.disable to properly account for tmds clock use. --- @@ -225,7 +235,7 @@ int sun4i_tmds_create(struct sun4i_hdmi *hdmi) init.ops = &sun4i_tmds_ops; init.parent_names = parents; init.num_parents = 2; - init.flags = CLK_SET_RATE_PARENT; + init.flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL; tmds->hdmi = hdmi; tmds->hw.init = &init; > Maxime > > -- > Maxime Ripard, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://l
Re: [PATCH v9 00/22] Re-use nvram module
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/nvram misc device. This module is now used only by x86 and m68k
> thanks to commit 3ba9faedc180 ("char: nvram: disable on ARM").
>
> The "generic" module cannot be used by x86 or m68k platforms because it
> cannot co-exist with the "CMOS" module. One reason for that is the
> CONFIG_GENERIC_NVRAM kludge in drivers/char/Makefile. Another reason is
> that automatically loading the appropriate module would be impossible
> because only one module can provide the char-major-10-144 alias.
>
> A multi-platform kernel binary needs a single, generic module. With this
> patch series, drivers/char/nvram.c becomes more generic and some of the
> arch-specific code gets moved under arch/. The nvram module is then
> usable by all m68k, powerpc and x86 platforms.
>
> This allows for removal of drivers/char/generic_nvram.c as well as a
> duplicate in arch/powerpc/kernel/nvram_64.c. By reducing the number of
> /dev/nvram char misc device implementations, the number of bugs and
> inconsistencies is also reduced.
>
> This approach reduces inconsistencies between PPC32 and PPC64 and also
> between PPC_PMAC and MAC. A uniform API has benefits for userspace.
>
> For example, some error codes for some ioctl calls become consistent
> across PowerPC platforms. The uniform API can potentially benefit any
> bootloader that works across the various platforms having XPRAM
> (e.g. Emile).
>
> This patch series was tested on Atari, Mac, PowerMac (both 32-bit and
> 64-bit) and ThinkPad hardware. AFAIK, it has not yet been tested on
> pSeries or CHRP.
>
> I think there are two possible merge strategies for this patch series.
> The char misc maintainer could take the entire series. Alternatively,
> the m68k maintainer could take patches 1 thru 16 (though some of these
> have nothing to do with m68k) and after those patches reach mainline
> the powerpc maintainer could take 17 thru 22.
I just took the whole series, thanks for doing this, looks good.
greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/7] drm/komeda: Add d71 layer
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)
---
.../drm/arm/display/include/malidp_utils.h| 17 ++
.../arm/display/komeda/d71/d71_component.c| 162 +-
.../drm/arm/display/komeda/komeda_pipeline.h | 10 +-
3 files changed, 185 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/include/malidp_utils.h
b/drivers/gpu/drm/arm/display/include/malidp_utils.h
index b7bf8db39a64..e97df5fbc9ea 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
@@ -25,4 +25,21 @@
num_tries; \
})
+/* the restriction of range is [start, end] */
+struct malidp_range {
+ u32 start;
+ u32 end;
+};
+
+static inline void set_range(struct malidp_range *rg, u32 start, u32 end)
+{
+ rg->start = start;
+ rg->end = end;
+}
+
+static inline bool in_range(struct malidp_range *rg, u32 v)
+{
+ return (v >= rg->start) && (v <= rg->end);
+}
+
#endif /* _MALIDP_UTILS_ */
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 18a36dd71567..0a602e875f5e 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -7,11 +7,171 @@
#include "d71_dev.h"
#include "komeda_kms.h"
#include "malidp_io.h"
+#include "komeda_framebuffer.h"
+
+static void get_resources_id(u32 hw_id, u32 *pipe_id, u32 *comp_id)
+{
+ u32 id = BLOCK_INFO_BLK_ID(hw_id);
+ u32 pipe = id;
+
+ switch (BLOCK_INFO_BLK_TYPE(hw_id)) {
+ case D71_BLK_TYPE_LPU_WB_LAYER:
+ id = KOMEDA_COMPONENT_WB_LAYER;
+ break;
+ case D71_BLK_TYPE_CU_SPLITTER:
+ id = KOMEDA_COMPONENT_SPLITTER;
+ break;
+ case D71_BLK_TYPE_CU_SCALER:
+ pipe = id / D71_PIPELINE_MAX_SCALERS;
+ id %= D71_PIPELINE_MAX_SCALERS;
+ id += KOMEDA_COMPONENT_SCALER0;
+ break;
+ case D71_BLK_TYPE_CU:
+ id += KOMEDA_COMPONENT_COMPIZ0;
+ break;
+ case D71_BLK_TYPE_LPU_LAYER:
+ pipe = id / D71_PIPELINE_MAX_LAYERS;
+ id %= D71_PIPELINE_MAX_LAYERS;
+ id += KOMEDA_COMPONENT_LAYER0;
+ break;
+ case D71_BLK_TYPE_DOU_IPS:
+ id += KOMEDA_COMPONENT_IPS0;
+ break;
+ case D71_BLK_TYPE_CU_MERGER:
+ id = KOMEDA_COMPONENT_MERGER;
+ break;
+ case D71_BLK_TYPE_DOU:
+ id = KOMEDA_COMPONENT_TIMING_CTRLR;
+ break;
+ default:
+ id = 0x;
+ }
+
+ if (comp_id)
+ *comp_id = id;
+
+ if (pipe_id)
+ *pipe_id = pipe;
+}
+
+static u32 get_valid_inputs(struct block_header *blk)
+{
+ u32 valid_inputs = 0, comp_id;
+ int i;
+
+ for (i = 0; i < PIPELINE_INFO_N_VALID_INPUTS(blk->pipeline_info); i++) {
+ get_resources_id(blk->input_ids[i], NULL, &comp_id);
+ if (comp_id == 0x)
+ continue;
+ valid_inputs |= BIT(comp_id);
+ }
+
+ return valid_inputs;
+}
+
+static u32 to_rot_ctrl(u32 rot)
+{
+ u32 lr_ctrl = 0;
+
+ switch (rot & DRM_MODE_ROTATE_MASK) {
+ case DRM_MODE_ROTATE_0:
+ lr_ctrl |= L_ROT(L_ROT_R0);
+ break;
+ case DRM_MODE_ROTATE_90:
+ lr_ctrl |= L_ROT(L_ROT_R90);
+ break;
+ case DRM_MODE_ROTATE_180:
+ lr_ctrl |= L_ROT(L_ROT_R180);
+ break;
+ case DRM_MODE_ROTATE_270:
+ lr_ctrl |= L_ROT(L_ROT_R270);
+ break;
+ }
+
+ if (rot & DRM_MODE_REFLECT_X)
+ lr_ctrl |= L_HFLIP;
+ if (rot & DRM_MODE_REFLECT_Y)
+ lr_ctrl |= L_VFLIP;
+
+ return lr_ctrl;
+}
+
+static void d71_layer_disable(struct komeda_component *c)
+{
+ malidp_write32_mask(c->reg, BLK_CONTROL, L_EN, 0);
+}
+
+static void d71_layer_update(struct komeda_component *c,
+struct komeda_component_state *state)
+{
+ struct komeda_layer_state *st = to_layer_st(state);
+ struct drm_plane_state *plane_st = state->plane->state;
+ struct drm_framebuffer *fb = plane_st->fb;
+ struct komeda_fb *kfb = to_kfb(fb);
+ u32 __iomem *reg = c->reg;
+ u32 ctrl_mask = L_EN | L_ROT(L_ROT_R270) | L_HFLIP | L_VFLIP | L_TBU_EN;
+ u32 ctrl = L_EN | to_rot_ctrl(st->rot);
+ int i;
+
+ for (i = 0; i < fb->format->num_planes; i++) {
+ malidp_write32(reg,
+
[PATCH v2 4/7] drm/komeda: Add D71 improc and timing_ctrlr
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/komeda_kms.h | 2 +
.../drm/arm/display/komeda/komeda_pipeline.h | 7 ++
3 files changed, 118 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 401053ef0a53..095779964518 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -282,18 +282,125 @@ static int d71_compiz_init(struct d71_dev *d71,
return 0;
}
+static void d71_improc_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_improc_state *st = to_improc_st(state);
+ u32 __iomem *reg = c->reg;
+ u32 index, input_hw_id;
+
+ for_each_changed_input(state, index) {
+ input_hw_id = state->active_inputs & BIT(index) ?
+ to_d71_input_id(&state->inputs[index]) : 0;
+ malidp_write32(reg, BLK_INPUT_ID0 + index * 4, input_hw_id);
+ }
+
+ malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
+}
+
+struct komeda_component_funcs d71_improc_funcs = {
+ .update = d71_improc_update,
+ .disable= d71_component_disable,
+};
+
static int d71_improc_init(struct d71_dev *d71,
struct block_header *blk, u32 __iomem *reg)
{
- DRM_DEBUG("Detect D71_improc.\n");
+ struct komeda_component *c;
+ struct komeda_improc *improc;
+ u32 pipe_id, comp_id, value;
+
+ get_resources_id(blk->block_info, &pipe_id, &comp_id);
+
+ c = komeda_component_add(&d71->pipes[pipe_id]->base, sizeof(*improc),
+comp_id,
+BLOCK_INFO_INPUT_ID(blk->block_info),
+&d71_improc_funcs, IPS_NUM_INPUT_IDS,
+get_valid_inputs(blk),
+IPS_NUM_OUTPUT_IDS, reg, "DOU%d_IPS", pipe_id);
+ if (IS_ERR(c)) {
+ DRM_ERROR("Failed to add improc component\n");
+ return PTR_ERR(c);
+ }
+
+ improc = to_improc(c);
+ improc->supported_color_depths = BIT(8) | BIT(10);
+ improc->supported_color_formats = DRM_COLOR_FORMAT_RGB444 |
+ DRM_COLOR_FORMAT_YCRCB444 |
+ DRM_COLOR_FORMAT_YCRCB422;
+ value = malidp_read32(reg, BLK_INFO);
+ if (value & IPS_INFO_CHD420)
+ improc->supported_color_formats |= DRM_COLOR_FORMAT_YCRCB420;
+
+ improc->supports_csc = true;
+ improc->supports_gamma = true;
return 0;
}
+static void d71_timing_ctrlr_disable(struct komeda_component *c)
+{
+ malidp_write32_mask(c->reg, BLK_CONTROL, BS_CTRL_EN, 0);
+}
+
+static void d71_timing_ctrlr_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct drm_crtc_state *crtc_st = state->crtc->state;
+ u32 __iomem *reg = c->reg;
+ struct videomode vm;
+ u32 value;
+
+ drm_display_mode_to_videomode(&crtc_st->adjusted_mode, &vm);
+
+ malidp_write32(reg, BS_ACTIVESIZE, HV_SIZE(vm.hactive, vm.vactive));
+ malidp_write32(reg, BS_HINTERVALS, BS_H_INTVALS(vm.hfront_porch,
+ vm.hback_porch));
+ malidp_write32(reg, BS_VINTERVALS, BS_V_INTVALS(vm.vfront_porch,
+ vm.vback_porch));
+
+ value = BS_SYNC_VSW(vm.vsync_len) | BS_SYNC_HSW(vm.hsync_len);
+ value |= vm.flags & DISPLAY_FLAGS_VSYNC_HIGH ? BS_SYNC_VSP : 0;
+ value |= vm.flags & DISPLAY_FLAGS_HSYNC_HIGH ? BS_SYNC_HSP : 0;
+ malidp_write32(reg, BS_SYNC, value);
+
+ malidp_write32(reg, BS_PROG_LINE, D71_DEFAULT_PREPRETCH_LINE - 1);
+ malidp_write32(reg, BS_PREFETCH_LINE, D71_DEFAULT_PREPRETCH_LINE);
+
+ /* configure bs control register */
+ value = BS_CTRL_EN | BS_CTRL_VM;
+
+ malidp_write32(reg, BLK_CONTROL, value);
+}
+
+struct komeda_component_funcs d71_timing_ctrlr_funcs = {
+ .update = d71_timing_ctrlr_update,
+ .disable= d71_timing_ctrlr_disable,
+};
+
static int d71_timing_ctrlr_init(struct d71_dev *d71,
struct block_header *blk, u32 __iomem *reg)
{
- DRM_DEBUG("Detect D71_timing_ctrlr.\n");
+ struct komeda_component *c;
+ struct komeda_timing_ctrlr *ctrlr;
+ u32 pipe_id, comp_id;
+
+ get_resources_id(blk->block_info, &pipe_id, &comp_id);
+
+ c = komeda_component_a
[PATCH v2 1/7] drm/komeda: Add d71_enum_resources and d71_cleanup
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
information of D71 HW, Like number of block contained and the number of
pipeline supported.
So the d71_enum_resources parsed GCU and create pipeline according
the GCU configuration, and then iterate and detect the blocks that
indicated by the GCU and block_header.
And this change also added two struct d71_dev/d71_pipeline to extend
komeda_dev/komeda_pipeline to add some d71 only members.
v2:
- Return the specific errno not -1.
- Use DRM_DEBUG as default debug msg printer.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/include/malidp_utils.h| 12 +
drivers/gpu/drm/arm/display/komeda/Makefile | 3 +-
.../arm/display/komeda/d71/d71_component.c| 120
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 138 -
.../gpu/drm/arm/display/komeda/d71/d71_dev.h | 50 ++
.../gpu/drm/arm/display/komeda/d71/d71_regs.h | 530 ++
.../drm/arm/display/komeda/komeda_pipeline.c | 16 +-
7 files changed, 852 insertions(+), 17 deletions(-)
create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h
create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h
diff --git a/drivers/gpu/drm/arm/display/include/malidp_utils.h
b/drivers/gpu/drm/arm/display/include/malidp_utils.h
index 63cc47cefcf8..b7bf8db39a64 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_utils.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_utils.h
@@ -13,4 +13,16 @@
#define dp_for_each_set_bit(bit, mask) \
for_each_set_bit((bit), ((unsigned long *)&(mask)), sizeof(mask) * 8)
+#define dp_wait_cond(__cond, __tries, __min_range, __max_range)\
+({ \
+ int num_tries = __tries;\
+ while (!__cond && (num_tries > 0)) {\
+ usleep_range(__min_range, __max_range); \
+ if (__cond) \
+ break; \
+ num_tries--;\
+ } \
+ num_tries; \
+})
+
#endif /* _MALIDP_UTILS_ */
diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
b/drivers/gpu/drm/arm/display/komeda/Makefile
index 1b875e5dc0f6..d593125236ae 100644
--- a/drivers/gpu/drm/arm/display/komeda/Makefile
+++ b/drivers/gpu/drm/arm/display/komeda/Makefile
@@ -16,6 +16,7 @@ komeda-y := \
komeda_private_obj.o
komeda-y += \
- d71/d71_dev.o
+ d71/d71_dev.o \
+ d71/d71_component.o
obj-$(CONFIG_DRM_KOMEDA) += komeda.o
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
new file mode 100644
index ..18a36dd71567
--- /dev/null
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
+ * Author: James.Qian.Wang
+ *
+ */
+#include "d71_dev.h"
+#include "komeda_kms.h"
+#include "malidp_io.h"
+
+static int d71_layer_init(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_Layer.\n");
+
+ return 0;
+}
+
+static int d71_wb_layer_init(struct d71_dev *d71,
+struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_Wb_Layer.\n");
+
+ return 0;
+}
+
+static int d71_compiz_init(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_compiz.\n");
+
+ return 0;
+}
+
+static int d71_improc_init(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_improc.\n");
+
+ return 0;
+}
+
+static int d71_timing_ctrlr_init(struct d71_dev *d71,
+struct block_header *blk, u32 __iomem *reg)
+{
+ DRM_DEBUG("Detect D71_timing_ctrlr.\n");
+
+ return 0;
+}
+
+int d71_probe_block(struct d71_dev *d71,
+ struct block_header *blk, u32 __iomem *reg)
+{
+ struct d71_pipeline *pipe;
+ int blk_id = BLOCK_INFO_BLK_ID(blk->block_info);
+
+ int err = 0;
+
+ switch (BLOCK_INFO_BLK_TYPE(blk->block_info)) {
+ case D71_BLK_TYPE_GCU:
+ break;
+
+ case D71_BLK_TYPE_LPU:
+ pipe = d71->pipes[blk_id];
+ pipe->lpu_addr = reg;
+ break;
+
+ case D71_BLK_TYPE_LPU_LAYER:
+ err = d71_layer_
[PATCH v2 0/7] D71 pipeline/component descovery and initialization
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, splitter will be added in the future. v2: - Rebase. - Use DRM_DEBUG as default msg printer - Return the specific errno not -1. james qian wang (Arm Technology China) (7): drm/komeda: Add d71_enum_resources and d71_cleanup drm/komeda: Add d71 layer drm/komeda: Add d71 compiz component drm/komeda: Add D71 improc and timing_ctrlr drm/komeda: Add komeda_assemble_pipelines drm/komeda: Add irq handling drm/komeda: Add debugfs node "register" for register dump .../drm/arm/display/include/malidp_utils.h| 29 + drivers/gpu/drm/arm/display/komeda/Makefile | 3 +- .../arm/display/komeda/d71/d71_component.c| 682 ++ .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 375 +- .../gpu/drm/arm/display/komeda/d71/d71_dev.h | 50 ++ .../gpu/drm/arm/display/komeda/d71/d71_regs.h | 530 ++ .../gpu/drm/arm/display/komeda/komeda_crtc.c | 18 + .../gpu/drm/arm/display/komeda/komeda_dev.c | 64 ++ .../gpu/drm/arm/display/komeda/komeda_dev.h | 51 ++ .../gpu/drm/arm/display/komeda/komeda_kms.c | 37 +- .../gpu/drm/arm/display/komeda/komeda_kms.h | 5 + .../drm/arm/display/komeda/komeda_pipeline.c | 111 ++- .../drm/arm/display/komeda/komeda_pipeline.h | 48 +- 13 files changed, 1973 insertions(+), 30 deletions(-) create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_component.c create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.h create mode 100644 drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/7] drm/komeda: Add d71 compiz component
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_pipeline.h | 26 --
2 files changed, 110 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 0a602e875f5e..401053ef0a53 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -96,6 +96,13 @@ static u32 to_rot_ctrl(u32 rot)
return lr_ctrl;
}
+static inline u32 to_d71_input_id(struct komeda_component_output *output)
+{
+ struct komeda_component *comp = output->component;
+
+ return comp ? (comp->hw_id + output->output_port) : 0;
+}
+
static void d71_layer_disable(struct komeda_component *c)
{
malidp_write32_mask(c->reg, BLK_CONTROL, L_EN, 0);
@@ -184,10 +191,93 @@ static int d71_wb_layer_init(struct d71_dev *d71,
return 0;
}
+static void d71_component_disable(struct komeda_component *c)
+{
+ u32 __iomem *reg = c->reg;
+ u32 i;
+
+ malidp_write32(reg, BLK_CONTROL, 0);
+
+ for (i = 0; i < c->max_active_inputs; i++)
+ malidp_write32(reg, BLK_INPUT_ID0 + (i << 2), 0);
+}
+
+static void compiz_enable_input(u32 __iomem *id_reg,
+ u32 __iomem *cfg_reg,
+ u32 input_hw_id,
+ struct komeda_compiz_input_cfg *cin)
+{
+ u32 ctrl = CU_INPUT_CTRL_EN;
+ u8 blend = cin->pixel_blend_mode;
+
+ if (blend == DRM_MODE_BLEND_PIXEL_NONE)
+ ctrl |= CU_INPUT_CTRL_PAD;
+ else if (blend == DRM_MODE_BLEND_PREMULTI)
+ ctrl |= CU_INPUT_CTRL_PMUL;
+
+ ctrl |= CU_INPUT_CTRL_ALPHA(cin->layer_alpha);
+
+ malidp_write32(id_reg, BLK_INPUT_ID0, input_hw_id);
+
+ malidp_write32(cfg_reg, CU_INPUT0_SIZE,
+ HV_SIZE(cin->hsize, cin->vsize));
+ malidp_write32(cfg_reg, CU_INPUT0_OFFSET,
+ HV_OFFSET(cin->hoffset, cin->voffset));
+ malidp_write32(cfg_reg, CU_INPUT0_CONTROL, ctrl);
+}
+
+static void d71_compiz_update(struct komeda_component *c,
+ struct komeda_component_state *state)
+{
+ struct komeda_compiz_state *st = to_compiz_st(state);
+ u32 __iomem *reg = c->reg;
+ u32 __iomem *id_reg, *cfg_reg;
+ u32 index, input_hw_id;
+
+ for_each_changed_input(state, index) {
+ id_reg = reg + index;
+ cfg_reg = reg + index * CU_PER_INPUT_REGS;
+ input_hw_id = to_d71_input_id(&state->inputs[index]);
+ if (state->active_inputs & BIT(index)) {
+ compiz_enable_input(id_reg, cfg_reg,
+ input_hw_id, &st->cins[index]);
+ } else {
+ malidp_write32(id_reg, BLK_INPUT_ID0, 0);
+ malidp_write32(cfg_reg, CU_INPUT0_CONTROL, 0);
+ }
+ }
+
+ malidp_write32(reg, BLK_SIZE, HV_SIZE(st->hsize, st->vsize));
+}
+
+struct komeda_component_funcs d71_compiz_funcs = {
+ .update = d71_compiz_update,
+ .disable= d71_component_disable,
+};
+
static int d71_compiz_init(struct d71_dev *d71,
struct block_header *blk, u32 __iomem *reg)
{
- DRM_DEBUG("Detect D71_compiz.\n");
+ struct komeda_component *c;
+ struct komeda_compiz *compiz;
+ u32 pipe_id, comp_id;
+
+ get_resources_id(blk->block_info, &pipe_id, &comp_id);
+
+ c = komeda_component_add(&d71->pipes[pipe_id]->base, sizeof(*compiz),
+comp_id,
+BLOCK_INFO_INPUT_ID(blk->block_info),
+&d71_compiz_funcs,
+CU_NUM_INPUT_IDS, get_valid_inputs(blk),
+CU_NUM_OUTPUT_IDS, reg,
+"CU%d", pipe_id);
+ if (IS_ERR(c))
+ return PTR_ERR(c);
+
+ compiz = to_compiz(c);
+
+ set_range(&compiz->hsize, D71_MIN_LINE_SIZE, d71->max_line_size);
+ set_range(&compiz->vsize, D71_MIN_VERTICAL_SIZE, d71->max_vsize);
return 0;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 03525330efe8..d75cc81ae9c0 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -204,6 +204,10 @@ static inline u16 component_changed_inputs(struct
komeda_component_state *st)
return component_disabling_inputs(st) | st->changed_active_inputs;
}
+#define for_each_changed_input(st, i)
[PATCH v2 5/7] drm/komeda: Add komeda_assemble_pipelines
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-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_dev.c | 6 ++
.../drm/arm/display/komeda/komeda_pipeline.c | 75 +++
.../drm/arm/display/komeda/komeda_pipeline.h | 2 +-
3 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 0fe6954fbbf4..a1160e2f07ec 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -143,6 +143,12 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
goto err_cleanup;
}
+ err = komeda_assemble_pipelines(mdev);
+ if (err) {
+ DRM_ERROR("assemble display pipelines failed.\n");
+ goto err_cleanup;
+ }
+
return mdev;
err_cleanup:
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
index f755280caa3e..c2e469164244 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
@@ -198,3 +198,78 @@ void komeda_component_destroy(struct komeda_dev *mdev,
{
devm_kfree(mdev->dev, c);
}
+
+static void komeda_component_dump(struct komeda_component *c)
+{
+ if (!c)
+ return;
+
+ DRM_DEBUG(" %s: ID %d-0x%08lx.\n",
+ c->name, c->id, BIT(c->id));
+ DRM_DEBUG(" max_active_inputs:%d, supported_inputs:
0x%08x.\n",
+ c->max_active_inputs, c->supported_inputs);
+ DRM_DEBUG(" max_active_outputs:%d, supported_outputs:
0x%08x.\n",
+ c->max_active_outputs, c->supported_outputs);
+}
+
+static void komeda_pipeline_dump(struct komeda_pipeline *pipe)
+{
+ struct komeda_component *c;
+ int id;
+
+ DRM_INFO("Pipeline-%d: n_layers: %d, n_scalers: %d, output: %s\n",
+pipe->id, pipe->n_layers, pipe->n_scalers,
+pipe->of_output_dev ? pipe->of_output_dev->full_name : "none");
+
+ dp_for_each_set_bit(id, pipe->avail_comps) {
+ c = komeda_pipeline_get_component(pipe, id);
+
+ komeda_component_dump(c);
+ }
+}
+
+static void komeda_component_verify_inputs(struct komeda_component *c)
+{
+ struct komeda_pipeline *pipe = c->pipeline;
+ struct komeda_component *input;
+ int id;
+
+ dp_for_each_set_bit(id, c->supported_inputs) {
+ input = komeda_pipeline_get_component(pipe, id);
+ if (!input) {
+ c->supported_inputs &= ~(BIT(id));
+ DRM_WARN("Can not find input(ID-%d) for component:
%s.\n",
+id, c->name);
+ continue;
+ }
+
+ input->supported_outputs |= BIT(c->id);
+ }
+}
+
+static void komeda_pipeline_assemble(struct komeda_pipeline *pipe)
+{
+ struct komeda_component *c;
+ int id;
+
+ dp_for_each_set_bit(id, pipe->avail_comps) {
+ c = komeda_pipeline_get_component(pipe, id);
+
+ komeda_component_verify_inputs(c);
+ }
+}
+
+int komeda_assemble_pipelines(struct komeda_dev *mdev)
+{
+ struct komeda_pipeline *pipe;
+ int i;
+
+ for (i = 0; i < mdev->n_pipelines; i++) {
+ pipe = mdev->pipelines[i];
+
+ komeda_pipeline_assemble(pipe);
+ komeda_pipeline_dump(pipe);
+ }
+
+ return 0;
+}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 943aa52189d4..f9b7f517a484 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -363,7 +363,7 @@ komeda_pipeline_add(struct komeda_dev *mdev, size_t size,
struct komeda_pipeline_funcs *funcs);
void komeda_pipeline_destroy(struct komeda_dev *mdev,
struct komeda_pipeline *pipe);
-
+int komeda_assemble_pipelines(struct komeda_dev *mdev);
struct komeda_component *
komeda_pipeline_get_component(struct komeda_pipeline *pipe, int id);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register
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) 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 exported since there are no users.
> >>>
> >>> Signed-off-by: Noralf Trønnes
> >>
>
>
>
> >>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> >>> index 381581b01d48..12129772be45 100644
> >>> --- a/drivers/gpu/drm/drm_drv.c
> >>> +++ b/drivers/gpu/drm/drm_drv.c
> >>> @@ -36,6 +36,7 @@
> >>>
> >>> #include
> >>> #include
> >>> +#include
> >>> #include
> >>>
> >>> #include "drm_crtc_internal.h"
> >>> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct drm_device *dev)
> >>> }
> >>> EXPORT_SYMBOL(drm_dev_unregister);
> >>>
> >>> +static void devm_drm_dev_init_release(void *data)
> >>> +{
> >>> + drm_dev_put(data);
> >
> > We need drm_dev_unplug() here, or this isn't safe.
>
> This function is only used to cover the error path if probe fails before
> devm_drm_dev_register() is called. devm_drm_dev_register_release() is
> the one that calls unplug. There are comments about this in the functions.
I think I get a prize for being ignorant and blind :-/
>
> >
> >>> +}
> >>> +
> >>> +/**
> >>> + * devm_drm_dev_init - Resource managed drm_dev_init()
> >>> + * @parent: Parent device object
> >>> + * @dev: DRM device
> >>> + * @driver: DRM driver
> >>> + *
> >>> + * Managed drm_dev_init(). The DRM device initialized with this function
> >>> is
> >>> + * automatically released on driver detach. You must supply a
> >
> > I think a bit more clarity here would be good:
> >
> > "... automatically released on driver unbind by callind drm_dev_unplug()."
> >
> >>> + * &drm_driver.release callback to control the finalization explicitly.
> >
> > I think a loud warning for these is in order:
> >
> > "WARNING:
> >
> > "In generally it is unsafe to use devm functions for drm structures
> > because the lifetimes of &drm_device and the underlying &device do not
> > match. This here works because it doesn't immediately free anything, but
> > only calls drm_dev_unplug(), which internally decrements the &drm_device
> > refcount through drm_dev_put().
> >
> > "All other drm structures must still be explicitly released in the
> > &drm_driver.release callback."
> >
> > While thinking about this I just realized that with this design we have no
> > good place to call drm_atomic_helper_shutdown(). Which we need to, or all
> > kinds of things will leak badly (connectors, fb, ...), but there's no
> > place to call it:
> > - unbind is too early, since we haven't yet called drm_dev_unplug, and the
> > drm_dev_unregister in there must be called _before_ we start to shut
> > down anything.
> > - drm_driver.release is way too late.
> >
> > Ofc for a real hotunplug there's no point in shutting down the hw (it's
> > already gone), but for a driver unload/unbind it would be nice if this
> > happens automatically and in the right order.
> >
> > So not sure what to do here really.
>
> How about this change: (it breaks the rule of pulling helpers into the
> core, so maybe we should put the devm_ functions into the simple KMS
> helper instead?)
Yeah smells a bit much like midlayer ... What would work is having a pile
more devm_ helper functions, so that we onion-unwrap everything correctly,
and in the right order. So:
- devm_drm_dev_init (always does a drm_dev_put())
- devm_drm_poll_enable (shuts down the poll helper with a devm action)
- devm_drm_mode_config_reset (does an atomic_helper_shutdown() as it's cleanup
action)
- devm_drm_dev_register (grabs an additional drm_dev_get() reference so it
can call drm_dev_unplug() unconditionally).
We'd need to make sure some of the cleanup actions dtrt when the device is
gone, but I think we can achieve that by liberally sprinkling
drm_dev_enter/exit over them, e.g. the the cleanup action for
drm_mode_config_reset would be:
{
if (drm_dev_enter())
return;
drm_atomic_helper_shutdown();
drm_dev_exit();
}
This would be analog to your shutdown parameter below.
Essentially I think we can only do the drm_dev_unplug autocleanup in a
given driver from devm_drm_dev_register iff all the cleanup actions have
been devm-ified, and there's nothing left in it's unbind callback. Because
if anything is left in its unbind callback that's a bug, since
drm_dev_unregister() (called through drm_dev_unplug) is the very first (or
at least one of the very first, before we start cleanup up) functions that
need to be called.
-Daniel
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 12129772be45..7ed9
Re: [PATCH 01/11] drm: Add devm_drm_dev_init/register
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 exported since there are no users.
>
> Signed-off-by: Noralf Trønnes
> ---
> Documentation/driver-model/devres.txt | 4 +
> drivers/gpu/drm/drm_drv.c | 106 ++
> include/drm/drm_drv.h | 6 ++
> 3 files changed, 116 insertions(+)
>
> diff --git a/Documentation/driver-model/devres.txt
> b/Documentation/driver-model/devres.txt
> index b277cafce71e..6eebc28d4c21 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -254,6 +254,10 @@ DMA
>dmam_pool_create()
>dmam_pool_destroy()
>
> +DRM
> + devm_drm_dev_init()
> + devm_drm_dev_register_with_fbdev()
> +
> GPIO
>devm_gpiod_get()
>devm_gpiod_get_index()
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 381581b01d48..12129772be45 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -36,6 +36,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include "drm_crtc_internal.h"
> @@ -871,6 +872,111 @@ void drm_dev_unregister(struct drm_device *dev)
> }
> EXPORT_SYMBOL(drm_dev_unregister);
>
> +static void devm_drm_dev_init_release(void *data)
> +{
> + drm_dev_put(data);
> +}
> +
> +/**
> + * devm_drm_dev_init - Resource managed drm_dev_init()
> + * @parent: Parent device object
> + * @dev: DRM device
> + * @driver: DRM driver
> + *
> + * Managed drm_dev_init(). The DRM device initialized with this function is
> + * automatically released on driver detach. You must supply a
> + * &drm_driver.release callback to control the finalization explicitly.
> + *
> + * Note: This function must be used together with
> + * devm_drm_dev_register_with_fbdev().
> + *
> + * RETURNS:
> + * 0 on success, or error code on failure.
> + */
> +int devm_drm_dev_init(struct device *parent,
> + struct drm_device *dev,
> + struct drm_driver *driver)
> +{
> + int ret;
> +
> + if (WARN_ON(!parent || !driver->release))
> + return -EINVAL;
> +
> + ret = drm_dev_init(dev, driver, parent);
> + if (ret)
> + return ret;
> +
> + /*
> + * This is a temporary release action that is used if probing fails
> + * before devm_drm_dev_register() is called.
> + */
> + ret = devm_add_action(parent, devm_drm_dev_init_release, dev);
> + if (ret)
> + devm_drm_dev_init_release(dev);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(devm_drm_dev_init);
> +
> +static void devm_drm_dev_register_release(void *data)
> +{
> + drm_dev_unplug(data);
> +}
> +
> +static int devm_drm_dev_register(struct drm_device *dev)
> +{
> + int ret;
> +
> + ret = drm_dev_register(dev, 0);
> + if (ret)
> + return ret;
> +
> + /*
> + * This has now served it's purpose, remove it to not mess up ref
> + * counting.
> + */
> + devm_remove_action(dev->dev, devm_drm_dev_init_release, dev);
> +
> + ret = devm_add_action(dev->dev, devm_drm_dev_register_release, dev);
If this fails I think the cleanup would go wrong. I think simpler if you
never remove the devm action from dev_init, and just grab an additional
drm_dev_get() reference here for drm_dev_unplug. We also need that for
correct onion cleanup in, so that for a normal unbind/driver unload we can
still do:
1. drm_dev_unregister() through drm_dev_unplug()
2. drm_atomic_helper_shutdown() and similar things (needs the drm_device
to still be around)
3. drm_dev_put()
I think that'll give us the cleaner onion unwrapping in the
unload/hotunplug/error case cleanup cases.
Also, this allows drivers to start using devm_drm_dev_init without having
to use devm_drm_dev_register(), which they have to do if they still have
non-devm-ified things in step 2 above in there unbind callback.
-Daniel
> + if (ret)
> + devm_drm_dev_register_release(dev);
> +
> + return ret;
> +}
> +
> +/**
> + * devm_drm_dev_register_with_fbdev - Resource managed drm_dev_register()
> + *including generic fbdev emulation
> + * @dev: DRM device to register
> + * @fbdev_bpp: Preferred bits per pixel for fbdev (optional)
> + *
> + * Managed drm_dev_register() that also calls drm_fbdev_generic_setup().
> + * The DRM device registered with this function is automatically
> unregistered on
> + * driver detach using drm_dev_unplug().
> + *
> + * Note: This function must be used together with devm_drm_dev_init().
> + *
> + * For testing driver detach can be triggered manually by writing to the
> driver
> + * 'unbind' file.
> + *
> + * RETURNS:
> + * 0 on success, negative error code on failure.
> + */
> +int devm_drm_dev_regi
Re: [PATCH V2] pwm: Add MediaTek MT8183 display PWM driver support
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 double buffer > > before writing register, and needs to select commit mode > > and use PWM_PERIOD/PWM_HIGH_WIDTH. > > > > Signed-off-by: Jitao Shi > > There is no difference compared to (implicit) v1 sent a few minutes > earlier, right? There was another patch sent with the same Subject last > week, so I assume the mail from today without "v2" in the Subject was a > mistake? > > > --- > Adding a paragraph below the tripple dash that points out what was > changed compared to the previous submission is a good idea to help > reviewers to more easily see what was changed. I guess you only adapted > the commit log as a reaction to Matthias Burgger's review? > > Best regards > Uwe > Yes, I miss the "V2" and fine tune the commit message. Best Regards Jitao ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm: Add debug prints for the various object lookup errors
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
> more debug prints, and unify their appearance.
>
> Signed-off-by: Ville Syrjälä
Instead of sprinkling these all over, what about the reverse route and
pushing this into drm_mode_object_find? We can dump id + object type, that
should be all we need really. If we go this way maybe add kerneldoc to the
various drm_*_find/lookup functions so this doesn't get copypasted again
...
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 5 +
> drivers/gpu/drm/drm_color_mgmt.c | 8 ++--
> drivers/gpu/drm/drm_connector.c | 5 -
> drivers/gpu/drm/drm_crtc.c| 12 +++-
> drivers/gpu/drm/drm_encoder.c | 4 +++-
> drivers/gpu/drm/drm_framebuffer.c | 4 +++-
> drivers/gpu/drm/drm_mode_object.c | 17 ++---
> drivers/gpu/drm/drm_plane.c | 13 +
> drivers/gpu/drm/drm_property.c| 12 +---
> drivers/gpu/drm/drm_vblank.c | 8 ++--
> 10 files changed, 66 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 9a1f41adfc67..06390307e5a3 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1321,11 +1321,14 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>
> obj = drm_mode_object_find(dev, file_priv, obj_id,
> DRM_MODE_OBJECT_ANY);
> if (!obj) {
> + DRM_DEBUG_ATOMIC("Unknown object ID %d\n", obj_id);
> ret = -ENOENT;
> goto out;
> }
>
> if (!obj->properties) {
> + DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
> + obj_id);
> drm_mode_object_put(obj);
> ret = -ENOENT;
> goto out;
> @@ -1352,6 +1355,8 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>
> prop = drm_mode_obj_find_prop_id(obj, prop_id);
> if (!prop) {
> + DRM_DEBUG_ATOMIC("Unknown property ID %d\n",
> + prop_id);
> drm_mode_object_put(obj);
> ret = -ENOENT;
> goto out;
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 07dcf47daafe..a99ee15b8328 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -245,8 +245,10 @@ int drm_mode_gamma_set_ioctl(struct drm_device *dev,
> return -EOPNOTSUPP;
>
> crtc = drm_crtc_find(dev, file_priv, crtc_lut->crtc_id);
> - if (!crtc)
> + if (!crtc) {
> + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_lut->crtc_id);
> return -ENOENT;
> + }
>
> if (crtc->funcs->gamma_set == NULL)
> return -ENOSYS;
> @@ -313,8 +315,10 @@ int drm_mode_gamma_get_ioctl(struct drm_device *dev,
> return -EOPNOTSUPP;
>
> crtc = drm_crtc_find(dev, file_priv, crtc_lut->crtc_id);
> - if (!crtc)
> + if (!crtc) {
> + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_lut->crtc_id);
> return -ENOENT;
> + }
>
> /* memcpy into gamma store */
> if (crtc_lut->gamma_size != crtc->gamma_size)
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 847539645558..8745eb132fd4 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1952,8 +1952,11 @@ int drm_mode_getconnector(struct drm_device *dev, void
> *data,
> memset(&u_mode, 0, sizeof(struct drm_mode_modeinfo));
>
> connector = drm_connector_lookup(dev, file_priv,
> out_resp->connector_id);
> - if (!connector)
> + if (!connector) {
> + DRM_DEBUG_KMS("Unknown connector ID %d\n",
> + out_resp->connector_id);
> return -ENOENT;
> + }
>
> drm_connector_for_each_possible_encoder(connector, encoder, i)
> encoders_count++;
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 7dabbaf033a1..e5f234ffcd23 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -369,8 +369,10 @@ int drm_mode_getcrtc(struct drm_device *dev,
> return -EOPNOTSUPP;
>
> crtc = drm_crtc_find(dev, file_priv, crtc_resp->crtc_id);
> - if (!crtc)
> + if (!crtc) {
> + DRM_DEBUG_KMS("Unknown CRTC ID %d\n", crtc_resp->crtc_id);
> return -ENOENT;
> + }
>
> plane = crtc->primary;
>
> @@ -586
[PATCH v2 7/7] drm/komeda: Add debugfs node "register" for register dump
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 Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 205 ++
.../gpu/drm/arm/display/komeda/komeda_dev.c | 52 +
.../gpu/drm/arm/display/komeda/komeda_dev.h | 5 +
.../drm/arm/display/komeda/komeda_pipeline.c | 20 ++
.../drm/arm/display/komeda/komeda_pipeline.h | 3 +
5 files changed, 285 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
index 095779964518..eb8f16e089e7 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
@@ -69,6 +69,42 @@ static u32 get_valid_inputs(struct block_header *blk)
return valid_inputs;
}
+static void get_values_from_reg(void __iomem *reg, u32 offset,
+ u32 count, u32 *val)
+{
+ u32 i, addr;
+
+ for (i = 0; i < count; i++) {
+ addr = offset + (i << 2);
+ /* 0xA4 is WO register */
+ if (addr != 0xA4)
+ val[i] = malidp_read32(reg, addr);
+ else
+ val[i] = 0xDEADDEAD;
+ }
+}
+
+static void dump_block_header(struct seq_file *sf, void __iomem *reg)
+{
+ struct block_header hdr;
+ u32 i, n_input, n_output;
+
+ d71_read_block_header(reg, &hdr);
+ seq_printf(sf, "BLOCK_INFO:\t\t0x%X\n", hdr.block_info);
+ seq_printf(sf, "PIPELINE_INFO:\t\t0x%X\n", hdr.pipeline_info);
+
+ n_output = PIPELINE_INFO_N_OUTPUTS(hdr.pipeline_info);
+ n_input = PIPELINE_INFO_N_VALID_INPUTS(hdr.pipeline_info);
+
+ for (i = 0; i < n_input; i++)
+ seq_printf(sf, "VALID_INPUT_ID%u:\t0x%X\n",
+ i, hdr.input_ids[i]);
+
+ for (i = 0; i < n_output; i++)
+ seq_printf(sf, "OUTPUT_ID%u:\t\t0x%X\n",
+ i, hdr.output_ids[i]);
+}
+
static u32 to_rot_ctrl(u32 rot)
{
u32 lr_ctrl = 0;
@@ -141,9 +177,76 @@ static void d71_layer_update(struct komeda_component *c,
malidp_write32_mask(reg, BLK_CONTROL, ctrl_mask, ctrl);
}
+static void d71_layer_dump(struct komeda_component *c, struct seq_file *sf)
+{
+ u32 v[15], i;
+ bool rich, rgb2rgb;
+ char *prefix;
+
+ get_values_from_reg(c->reg, LAYER_INFO, 1, &v[14]);
+ if (v[14] & 0x1) {
+ rich = true;
+ prefix = "LR_";
+ } else {
+ rich = false;
+ prefix = "LS_";
+ }
+
+ rgb2rgb = !!(v[14] & L_INFO_CM);
+
+ dump_block_header(sf, c->reg);
+
+ seq_printf(sf, "%sLAYER_INFO:\t\t0x%X\n", prefix, v[14]);
+
+ get_values_from_reg(c->reg, 0xD0, 1, v);
+ seq_printf(sf, "%sCONTROL:\t\t0x%X\n", prefix, v[0]);
+ if (rich) {
+ get_values_from_reg(c->reg, 0xD4, 1, v);
+ seq_printf(sf, "LR_RICH_CONTROL:\t0x%X\n", v[0]);
+ }
+ get_values_from_reg(c->reg, 0xD8, 4, v);
+ seq_printf(sf, "%sFORMAT:\t\t0x%X\n", prefix, v[0]);
+ seq_printf(sf, "%sIT_COEFFTAB:\t\t0x%X\n", prefix, v[1]);
+ seq_printf(sf, "%sIN_SIZE:\t\t0x%X\n", prefix, v[2]);
+ seq_printf(sf, "%sPALPHA:\t\t0x%X\n", prefix, v[3]);
+
+ get_values_from_reg(c->reg, 0x100, 3, v);
+ seq_printf(sf, "%sP0_PTR_LOW:\t\t0x%X\n", prefix, v[0]);
+ seq_printf(sf, "%sP0_PTR_HIGH:\t\t0x%X\n", prefix, v[1]);
+ seq_printf(sf, "%sP0_STRIDE:\t\t0x%X\n", prefix, v[2]);
+
+ get_values_from_reg(c->reg, 0x110, 2, v);
+ seq_printf(sf, "%sP1_PTR_LOW:\t\t0x%X\n", prefix, v[0]);
+ seq_printf(sf, "%sP1_PTR_HIGH:\t\t0x%X\n", prefix, v[1]);
+ if (rich) {
+ get_values_from_reg(c->reg, 0x118, 1, v);
+ seq_printf(sf, "LR_P1_STRIDE:\t\t0x%X\n", v[0]);
+
+ get_values_from_reg(c->reg, 0x120, 2, v);
+ seq_printf(sf, "LR_P2_PTR_LOW:\t\t0x%X\n", v[0]);
+ seq_printf(sf, "LR_P2_PTR_HIGH:\t\t0x%X\n", v[1]);
+
+ get_values_from_reg(c->reg, 0x130, 12, v);
+ for (i = 0; i < 12; i++)
+ seq_printf(sf, "LR_YUV_RGB_COEFF%u:\t0x%X\n", i, v[i]);
+ }
+
+ if (rgb2rgb) {
+ get_values_from_reg(c->reg, LAYER_RGB_RGB_COEFF0, 12, v);
+ for (i = 0; i < 12; i++)
+ seq_printf(sf, "LS_RGB_RGB_COEFF%u:\t0x%X\n", i, v[i]);
+ }
+
+ get_values_from_reg(c->reg, 0x160, 3, v);
+ seq_printf(sf, "%sAD_CONTROL:\t\t0x%X\n", prefix, v[0]);
+ seq_printf(sf, "%sAD_H_CROP:\t\t0x%X\n", prefix, v[1]);
+ seq_printf(sf, "%sAD_V_CROP:\t\t0x%X\n", prefix, v[2]);
+}
[Bug 199115] [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081
https://bugzilla.kernel.org/show_bug.cgi?id=199115 Hans de Goede (jwrdego...@fedoraproject.org) changed: What|Removed |Added Status|NEW |RESOLVED CC||jwrdego...@fedoraproject.or ||g Resolution|--- |CODE_FIX --- Comment #2 from Hans de Goede (jwrdego...@fedoraproject.org) --- As discussed in https://bugs.freedesktop.org/show_bug.cgi?id=106470, gfx are working on the Thecus N5550 NAS now, so this can be closed. The only remaining issue is the gma500 driver thinking there is an LVDS panel, this can be worked around by passing: "video=LVDS-1:d" on the kernel commandline. Fixing the LVDS issue properly (with a DMI based blacklist) is being tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=1665766 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/3] drm: Sync errno values for property lookup errors
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 atomic and legacy codepaths.
>
> Signed-off-by: Ville Syrjälä
Matches
https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
Reviewed-by: Daniel Vetter
Any igts that blow up with this? We should have at least some trying to do
invalid stuff ...
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> drivers/gpu/drm/drm_mode_object.c | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 06390307e5a3..2a54f826cf65 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1330,7 +1330,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
> DRM_DEBUG_ATOMIC("Object ID %d has no properties\n",
>obj_id);
> drm_mode_object_put(obj);
> - ret = -ENOENT;
> + ret = -EINVAL;
> goto out;
> }
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c
> b/drivers/gpu/drm/drm_mode_object.c
> index e8dac94d576d..31730d935842 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -527,6 +527,7 @@ int drm_mode_obj_set_property_ioctl(struct drm_device
> *dev, void *data,
> property = drm_mode_obj_find_prop_id(arg_obj, arg->prop_id);
> if (!property) {
> DRM_DEBUG_KMS("Unknown property ID %d\n", arg->prop_id);
> + ret = -ENOENT;
> goto out_unref;
> }
>
> --
> 2.19.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/7] drm/komeda: Add irq handling
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:
komeda_kms_irq_handler(int irq, void *data)
/* step 1. call into the CHIP to recognize event */
mdev->funcs->irq_handler(mdev, &evts);
/* step 2. notify the crtc to handle the events */
for (i = 0; i < kms->n_crtcs; i++)
komeda_crtc_handle_event(&kms->crtcs[i], &evts);
v2:
- Move get IRQ number into this change.
- Enable irq before drm_dev_register.
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 237 ++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 18 ++
.../gpu/drm/arm/display/komeda/komeda_dev.c | 6 +
.../gpu/drm/arm/display/komeda/komeda_dev.h | 46
.../gpu/drm/arm/display/komeda/komeda_kms.c | 37 ++-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
6 files changed, 345 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index b87ffae62dbe..afc13d3b3afc 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -7,6 +7,240 @@
#include "d71_dev.h"
#include "malidp_io.h"
+static u64 get_lpu_event(struct d71_pipeline *d71_pipeline)
+{
+ u32 __iomem *reg = d71_pipeline->lpu_addr;
+ u32 status, raw_status;
+ u64 evts = 0ULL;
+
+ raw_status = malidp_read32(reg, BLK_IRQ_RAW_STATUS);
+ if (raw_status & LPU_IRQ_IBSY)
+ evts |= KOMEDA_EVENT_IBSY;
+ if (raw_status & LPU_IRQ_EOW)
+ evts |= KOMEDA_EVENT_EOW;
+
+ if (raw_status & (LPU_IRQ_ERR | LPU_IRQ_IBSY)) {
+ u32 restore = 0, tbu_status;
+ /* Check error of LPU status */
+ status = malidp_read32(reg, BLK_STATUS);
+ if (status & LPU_STATUS_AXIE) {
+ restore |= LPU_STATUS_AXIE;
+ evts |= KOMEDA_ERR_AXIE;
+ }
+ if (status & LPU_STATUS_ACE0) {
+ restore |= LPU_STATUS_ACE0;
+ evts |= KOMEDA_ERR_ACE0;
+ }
+ if (status & LPU_STATUS_ACE1) {
+ restore |= LPU_STATUS_ACE1;
+ evts |= KOMEDA_ERR_ACE1;
+ }
+ if (status & LPU_STATUS_ACE2) {
+ restore |= LPU_STATUS_ACE2;
+ evts |= KOMEDA_ERR_ACE2;
+ }
+ if (status & LPU_STATUS_ACE3) {
+ restore |= LPU_STATUS_ACE3;
+ evts |= KOMEDA_ERR_ACE3;
+ }
+ if (restore != 0)
+ malidp_write32_mask(reg, BLK_STATUS, restore, 0);
+
+ restore = 0;
+ /* Check errors of TBU status */
+ tbu_status = malidp_read32(reg, LPU_TBU_STATUS);
+ if (tbu_status & LPU_TBU_STATUS_TCF) {
+ restore |= LPU_TBU_STATUS_TCF;
+ evts |= KOMEDA_ERR_TCF;
+ }
+ if (tbu_status & LPU_TBU_STATUS_TTNG) {
+ restore |= LPU_TBU_STATUS_TTNG;
+ evts |= KOMEDA_ERR_TTNG;
+ }
+ if (tbu_status & LPU_TBU_STATUS_TITR) {
+ restore |= LPU_TBU_STATUS_TITR;
+ evts |= KOMEDA_ERR_TITR;
+ }
+ if (tbu_status & LPU_TBU_STATUS_TEMR) {
+ restore |= LPU_TBU_STATUS_TEMR;
+ evts |= KOMEDA_ERR_TEMR;
+ }
+ if (tbu_status & LPU_TBU_STATUS_TTF) {
+ restore |= LPU_TBU_STATUS_TTF;
+ evts |= KOMEDA_ERR_TTF;
+ }
+ if (restore != 0)
+ malidp_write32_mask(reg, LPU_TBU_STATUS, restore, 0);
+ }
+
+ malidp_write32(reg, BLK_IRQ_CLEAR, raw_status);
+ return evts;
+}
+
+static u64 get_cu_event(struct d71_pipeline *d71_pipeline)
+{
+ u32 __iomem *reg = d71_pipeline->cu_addr;
+ u32 status, raw_status;
+ u64 evts = 0ULL;
+
+ raw_status = malidp_read32(reg, BLK_IRQ_RAW_STATUS);
+ if (raw_status & CU_IRQ_OVR)
+ evts |= KOMEDA_EVENT_OVR;
+
+ if (raw_status & (CU_IRQ_ERR | CU_IRQ_OVR)) {
+ status = malidp_read32(reg, BLK_STATUS) & 0x7FFF;
+ if (status & CU_STATUS_CPE)
+ evts |= KOMEDA_ERR_CPE;
+ if (status & CU_STATUS_ZME)
+ evts |= KOMEDA_ERR_ZME;
+ if (status & CU_STATUS_CFGE)
+ evts |= KOMEDA_ERR_CF
Re: [PATCH 3/3] drm: Add a debug print for drm_modeset_backoff()
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 obvious.
>
> Signed-off-by: Ville Syrjälä
Makes sense. Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_modeset_lock.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c
> b/drivers/gpu/drm/drm_modeset_lock.c
> index 81dd11901ffd..1277ff18d993 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -295,6 +295,8 @@ int drm_modeset_backoff(struct drm_modeset_acquire_ctx
> *ctx)
> {
> struct drm_modeset_lock *contended = ctx->contended;
>
> + DRM_DEBUG_KMS("Retrying to avoid deadlock\n");
> +
> ctx->contended = NULL;
>
> if (WARN_ON(!contended))
> --
> 2.19.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Enhance dma-fence tracing
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 > > > > 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 these common dma-fence level tracepoints, the userspace tools can > > > > establish a detailed view of the client <-> HW flow across different > > > > kernels. There is a strong ask to have this available, so that the > > > > userspace developer can effectively assess if they're doing a good job > > > > about feeding the beast of a GPU hardware. > > > > > > > > In the case of needing to look into more fine-grained details of how > > > > kernel internals work towards the goal of feeding the beast, the tools > > > > may optionally amend the dma-fence tracing information with the driver > > > > implementation specific. But for such cases, the tools should have a > > > > graceful degradation in case the expected extra tracepoints have > > > > changed or their format differs from the expected, as the kernel > > > > implementation internals are not expected to stay the same. > > > > > > > > It is important to distinguish between tracing for the purpose of client > > > > flow visualisation and tracing for the purpose of low-level kernel > > > > debugging. The latter is highly implementation specific, tied to > > > > a particular HW and driver, whereas the former addresses a common goal > > > > of user level tracing and likely a common set of userspace tools. > > > > Having made the distinction that these tracepoints will be consumed for > > > > client API tooling, we raise the spectre of tracepoint ABI stability. It > > > > is hoped that by defining a common set of dma-fence tracepoints, we > > > > avoid > > > > the pitfall of exposing low level details and so restrict ourselves only > > > > to the high level flow that is applicable to all drivers and hardware. > > > > Thus the reserved guarantee that this set of tracepoints will be stable > > > > (with the emphasis on depicting client <-> HW flow as opposed to > > > > driver <-> HW). > > > > > > > > In terms of specific changes to the dma-fence tracing, we remove the > > > > emission of the strings for every tracepoint (reserving them for > > > > dma_fence_init for cases where they have unique dma_fence_ops, and > > > > preferring to have descriptors for the whole fence context). strings do > > > > not pack as well into the ftrace ringbuffer and we would prefer to > > > > reduce the amount of indirect callbacks required for frequent tracepoint > > > > emission. > > > > > > > > Signed-off-by: Chris Wilson > > > > Cc: Joonas Lahtinen > > > > Cc: Tvrtko Ursulin > > > > Cc: Alex Deucher > > > > Cc: "Christian König" > > > > Cc: Eric Anholt > > > > Cc: Pierre-Loup Griffais > > > > Cc: Michael Sartain > > > > Cc: Steven Rostedt > > > > > > In general yes please! If possible please separate out the changes to > > > the common dma_fence infrastructure from the i915 changes. > > > > Sure, I was just stressing the impact: remove some randomly placed > > internal debugging tracepoints, try to define useful ones instead :) > > > > On the list of things to do was to convert at least 2 other drivers > > (I was thinking nouveau/msm for simplicity, vc4 for a simpler > > introduction to drm_sched than amdgpu) over to be sure we have the right > > tracepoints. > > I think sprinkling these over the scheduler (maybe just as an opt-in, > for the case where the driver doesn't have some additional queueing > somewhere) would be good. I haven't checked whether it fits, but would > give you a bunch of drivers at once. It might also not cover all the > cases (I guess the wait related ones would need to be somewhere else). And the other thing (that got explicitly asked for!) was that we have some igt to make sure we don't surreptitiously break the tracepoints in future. Another task would to devise the set of tracepoints to describe the modesetting flow; that more or less is the flow of atomic helpers I guess: prepare; wait-on-fences; commit; signal; cleanup. For system snooping, knowing a target frame (msc or ust) and how late it was delayed and the HW execution flow up to the frame and being able to tie that back to the GL/VK client is the grand plan. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/komeda: Fix a signedness bug
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: Dan Carpenter
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> index a0bf7050037a..a52da6180c69 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> @@ -82,7 +82,7 @@ struct komeda_dev {
> struct clk *mclk;
>
> /** @irq: irq number */
> -u32 irq;
> +int irq;
>
Hi Dan:
Thank you.
Liviu and I discussed this problem, and we decided to fix it by
Remove IRQ parsing from initial series:
https://patchwork.freedesktop.org/patch/277409/
And add it back when add the fully IRQ handling:
https://patchwork.freedesktop.org/patch/279491/
> int n_pipelines;
> struct komeda_pipeline *pipelines[KOMEDA_MAX_PIPELINES];
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Enhance dma-fence tracing
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 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 these common dma-fence level tracepoints, the userspace tools can > > > > > establish a detailed view of the client <-> HW flow across different > > > > > kernels. There is a strong ask to have this available, so that the > > > > > userspace developer can effectively assess if they're doing a good job > > > > > about feeding the beast of a GPU hardware. > > > > > > > > > > In the case of needing to look into more fine-grained details of how > > > > > kernel internals work towards the goal of feeding the beast, the tools > > > > > may optionally amend the dma-fence tracing information with the driver > > > > > implementation specific. But for such cases, the tools should have a > > > > > graceful degradation in case the expected extra tracepoints have > > > > > changed or their format differs from the expected, as the kernel > > > > > implementation internals are not expected to stay the same. > > > > > > > > > > It is important to distinguish between tracing for the purpose of > > > > > client > > > > > flow visualisation and tracing for the purpose of low-level kernel > > > > > debugging. The latter is highly implementation specific, tied to > > > > > a particular HW and driver, whereas the former addresses a common goal > > > > > of user level tracing and likely a common set of userspace tools. > > > > > Having made the distinction that these tracepoints will be consumed > > > > > for > > > > > client API tooling, we raise the spectre of tracepoint ABI stability. > > > > > It > > > > > is hoped that by defining a common set of dma-fence tracepoints, we > > > > > avoid > > > > > the pitfall of exposing low level details and so restrict ourselves > > > > > only > > > > > to the high level flow that is applicable to all drivers and hardware. > > > > > Thus the reserved guarantee that this set of tracepoints will be > > > > > stable > > > > > (with the emphasis on depicting client <-> HW flow as opposed to > > > > > driver <-> HW). > > > > > > > > > > In terms of specific changes to the dma-fence tracing, we remove the > > > > > emission of the strings for every tracepoint (reserving them for > > > > > dma_fence_init for cases where they have unique dma_fence_ops, and > > > > > preferring to have descriptors for the whole fence context). strings > > > > > do > > > > > not pack as well into the ftrace ringbuffer and we would prefer to > > > > > reduce the amount of indirect callbacks required for frequent > > > > > tracepoint > > > > > emission. > > > > > > > > > > Signed-off-by: Chris Wilson > > > > > Cc: Joonas Lahtinen > > > > > Cc: Tvrtko Ursulin > > > > > Cc: Alex Deucher > > > > > Cc: "Christian König" > > > > > Cc: Eric Anholt > > > > > Cc: Pierre-Loup Griffais > > > > > Cc: Michael Sartain > > > > > Cc: Steven Rostedt > > > > > > > > In general yes please! If possible please separate out the changes to > > > > the common dma_fence infrastructure from the i915 changes. > > > > > > Sure, I was just stressing the impact: remove some randomly placed > > > internal debugging tracepoints, try to define useful ones instead :) > > > > > > On the list of things to do was to convert at least 2 other drivers > > > (I was thinking nouveau/msm for simplicity, vc4 for a simpler > > > introduction to drm_sched than amdgpu) over to be sure we have the right > > > tracepoints. > > > > I think sprinkling these over the scheduler (maybe just as an opt-in, > > for the case where the driver doesn't have some additional queueing > > somewhere) would be good. I haven't checked whether it fits, but would > > give you a bunch of drivers at once. It might also not cover all the > > cases (I guess the wait related ones would need to be somewhere else). > > And the other thing (that got explicitly asked for!) was that we have > some igt to make sure we don't surreptitiously break the tracepoints > in future. > > Another task would to devise the set of tracepoints to describe the > modesetting flow; that more or less is the flow of atomic helpers I > guess: prepare; wait-on-fences; commit; signal; cleanup. For system > snooping, knowing a target frame (msc or ust) and how late it was > delayed and the HW execution flow up to the frame and being able to tie > that back to the GL/VK client is the grand plan. Yeah with atomic helpers this should be doable, as long as the driver uses the commit tracking part of the helpers. That's the st
Re: [PATCH RESEND v5 00/23] drm/sun4i: Support for linear and tiled YUV formats with the frontend
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 supported for every format handled by the frontend. > > > > The tiling mode used by the VPU on Allwinner platforms is also supported > > by this series and a dedicated fourcc modifier is introduced, along with > > a specific ioctl for allocating tiled buffers. > > > > New common fourcc helpers are also introduced in this series, especially > > related to YUV formats. > > > > This was tested on the A33, A20 and A10 platforms and all supported > > features work properly on them. Framebuffer offsets and source > > positions are not supported at this point. > > I've applied everything, however I can't see the ioctl you mentionned > anywhere? Thanks for the merge! Oops, I should have updated the cover letter more carefully: this was removed from the series and I didn't come up with an implementation of the generic ioctl yet. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
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_gfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_g4x_gfx);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_g4x_gfx);
> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044, quirk_iommu_g4x_gfx);
> >
> > static void quirk_iommu_rwbf(struct pci_dev *dev)
> > {
> > @@ -5457,7 +5458,6 @@ static void quirk_calpella_no_shadow_gtt(struct
> > pci_dev *dev)
> > }
> > }
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0040,
> > quirk_calpella_no_shadow_gtt);
> > -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044,
> > quirk_calpella_no_shadow_gtt);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0062,
> > quirk_calpella_no_shadow_gtt);
> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x006a,
> > quirk_calpella_no_shadow_gtt);
>
> This seems to make sense to me. Joonas, any comments or objections?
This is ironlake, which has a huge iommu hack in the gpu driver to
work around hard hangs, which:
- causes massive stalls and kills performance
- isn't well tested (it's the only one that needs this), so tends to break
So if we do this then imo we should:
- probably nuke that w/a too (check for needs_idle_maps and all the
related stuff in i915_gem_gtt.c)
- roll it out for all affected chips (i.e. need to include 0x0040).
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. So if we make a policy change to also disable it anywhere
where it doesn't work well (instead of not at all), there's a pile
more platforms to switch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
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, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_g4x_gfx);
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044, quirk_iommu_g4x_gfx);
>
> static void quirk_iommu_rwbf(struct pci_dev *dev)
> {
> @@ -5457,7 +5458,6 @@ static void quirk_calpella_no_shadow_gtt(struct pci_dev
> *dev)
> }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0040,
> quirk_calpella_no_shadow_gtt);
> -DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0044,
> quirk_calpella_no_shadow_gtt);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0062,
> quirk_calpella_no_shadow_gtt);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x006a,
> quirk_calpella_no_shadow_gtt);
This seems to make sense to me. Joonas, any comments or objections?
Regards,
Joerg
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] dt-bindings: display: armada: Add display subsystem binding
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-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
> > > > > > ---
> > > > > > .../display/armada/marvell-armada-drm.txt | 24
> > > > > > +++
> > > > > > 1 file changed, 24 insertions(+)
> > > > > >
> > > > > > diff --git
> > > > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > >
> > > > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > index de4cca9432c8..3dbfa8047f0b 100644
> > > > > > ---
> > > > > > a/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/display/armada/marvell-armada-drm.txt
> > > > > > @@ -1,3 +1,27 @@
> > > > > > +Marvell Armada DRM master device
> > > > > > +
> > > > > > +
> > > > > > +The Marvell Armada DRM master device is a virtual device needed to
> > > > > > list all
> > > > > > +nodes that comprise the graphics subsystem.
> > > > > > +
> > > > > > +Required properties:
> > > > > > +
> > > > > > + - compatible: value should be "marvell,dove-display-subsystem",
> > > > > > + "marvell,armada-display-subsystem"
> > > > > > + - ports: a list of phandles pointing to display interface ports
> > > > > > of CRTC
> > > > > > + devices
> > > > > > + - memory-region: phandle to a node describing memory to be used
> > > > > > for the
> > > > > > + framebuffer
> > > > > > +
> > > > > > +Example:
> > > > > > +
> > > > > > + display-subsystem {
> > > > > > + compatible = "marvell,dove-display-subsystem",
> > > > > > +"marvell,armada-display-subsystem";
> > > > > > + memory-region = <&display_reserved>;
> > > > > > + ports = <&lcd0_port>;
> > > > >
> > > > > If there is only one device, you don't need this virtual node.
> > > >
> > > > By "one device" you mean one LCD controller (CRTC)?
> > >
> > > Yes.
> >
> > How does that work (as far as the Linux implementation) ? I can't see
> > a way that could work, while allowing the flexibility that Armada DRM
> > allows (two completely independent LCD controllers as two separate DRM
> > devices vs one DRM device containing both LCD controllers.)
> >
> > > > I suppose in the (single CRTC) example case, the display-subsystem node
> > > > used to associate it with the memory region reserved for allocating the
> > > > frame buffers from. Could that be done differently?
> > >
> > > Move memory-region to the LCD controller node.
> >
> > That doesn't work - it would appear in the wrong part of the driver.
>
> Why? You can fetch properties from other nodes.
>
> If you have 2 CRTCs, do you have 1 or 2 reserved memory regions? I'd
> think 2 with each one in the corresponding LCDC that uses them would
> be more flexible.
There would still be one reserved memory region, since it is shared
between both LCDCs.
> Or just get the data out of the /reserved-memory node directly. Surely
> it has a compatible that you can find it with.
I see that the DT reserved memory support has progressed since I wrote
the armada code to deal with it, and it's now possible to make use of
reserved memory via of_reserved_mem_lookup() rather than using the
RESERVEDMEM_OF_DECLARE() and so forth.
> > > > Also, if the node is indeed made optional, then it's going to
> > > > complicate things on the DRM side. Currently the driver that binds to
> > > > the node creates the DRM device once it sees all the components
> > > > connected to the ports appear. If we loose it, then the LCD controller
> > > > driver would somehow need to find out that it's alone and create the
> > > > DRM device itself.
> > >
> > > DT is not the only way to create devices. The DRM driver can bind to
> > > the LCDC node and then create a child CRTC device (or even multiple
> > > ones for h/w with multiple pipelines).
> >
> > That seems completely upside down and rediculous to me - are you
> > really suggesting that we should have some kind of virtual device
> > in DT, and omit the _real_ physical devices for that, having the
> > driver create the device with all the appropriate SoC resources?
>
> We create child platform devices that inherit from the parent in DT
> all the time. MFD child drivers are a common case. Sometime the child
> devices have DT nodes and sometimes they don't.
I still don't think what you're saying is the right way to go a
Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
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. So if we make a policy change to also disable it anywhere > where it doesn't work well (instead of not at all), there's a pile > more platforms to switch. I think its best to just disable iommu for the igfx devices on these platforms. Can you pick up Eric's patch and extend it with the list of affected platforms? Thanks, Joerg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/5] Implement komeda DRM-Plane
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 this build function the plane_state
will be covert to komeda private component states to represent the real
HW configuration.
Beside that also added some basic functions for operating the komeda
private object.
v2:
- Rebase
- Introduce struct komeda_data_flow_cfg
- Update code after applied commit:
b962a12050a3 ("drm/atomic: integrate modeset lock with private objects")
james qian wang (Arm Technology China) (5):
drm: Add drm_atomic_get_old/new_private_obj_state
drm/komeda: Add komeda_pipeline/component_get_state_and_set_user
drm/komeda: Initialize komeda component as drm private object
drm/komeda: Add komeda_build_layer_data_flow
drm/komeda: Add komeda_plane/plane_helper_funcs
drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
.../gpu/drm/arm/display/komeda/komeda_kms.c | 3 +-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 2 +-
.../drm/arm/display/komeda/komeda_pipeline.h | 24 ++
.../display/komeda/komeda_pipeline_state.c| 406 ++
.../gpu/drm/arm/display/komeda/komeda_plane.c | 128 ++
.../arm/display/komeda/komeda_private_obj.c | 220 +-
drivers/gpu/drm/drm_atomic.c | 45 +-
include/drm/drm_atomic.h | 6 +
9 files changed, 817 insertions(+), 18 deletions(-)
create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/5] drm: Add drm_atomic_get_old/new_private_obj_state
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)
---
drivers/gpu/drm/drm_atomic.c | 45 +++-
include/drm/drm_atomic.h | 6 +
2 files changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 008224f376fe..900f9f9dedad 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -775,6 +775,50 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state
*state,
}
EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
+/**
+ * drm_atomic_get_old_private_obj_state
+ * @state: global atomic state object
+ * @obj: private_obj to grab
+ *
+ * This function returns the old private object state for the given
private_obj,
+ * or NULL if the private_obj is not part of the global atomic state.
+ */
+struct drm_private_state *
+drm_atomic_get_old_private_obj_state(struct drm_atomic_state *state,
+struct drm_private_obj *obj)
+{
+ int i;
+
+ for (i = 0; i < state->num_private_objs; i++)
+ if (obj == state->private_objs[i].ptr)
+ return state->private_objs[i].old_state;
+
+ return NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_old_private_obj_state);
+
+/**
+ * drm_atomic_get_new_private_obj_state
+ * @state: global atomic state object
+ * @obj: private_obj to grab
+ *
+ * This function returns the new private object state for the given
private_obj,
+ * or NULL if the private_obj is not part of the global atomic state.
+ */
+struct drm_private_state *
+drm_atomic_get_new_private_obj_state(struct drm_atomic_state *state,
+struct drm_private_obj *obj)
+{
+ int i;
+
+ for (i = 0; i < state->num_private_objs; i++)
+ if (obj == state->private_objs[i].ptr)
+ return state->private_objs[i].new_state;
+
+ return NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_new_private_obj_state);
+
/**
* drm_atomic_get_connector_state - get connector state
* @state: global atomic state object
@@ -1214,4 +1258,3 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
minor->debugfs_root, minor);
}
#endif
-
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index cac4a1b6b0e8..a4489b2fe740 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -443,6 +443,12 @@ void drm_atomic_private_obj_fini(struct drm_private_obj
*obj);
struct drm_private_state * __must_check
drm_atomic_get_private_obj_state(struct drm_atomic_state *state,
struct drm_private_obj *obj);
+struct drm_private_state *
+drm_atomic_get_old_private_obj_state(struct drm_atomic_state *state,
+struct drm_private_obj *obj);
+struct drm_private_state *
+drm_atomic_get_new_private_obj_state(struct drm_atomic_state *state,
+struct drm_private_obj *obj);
/**
* drm_atomic_get_existing_crtc_state - get crtc state, if it exists
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/5] drm/komeda: Add komeda_pipeline/component_get_state_and_set_user
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 modeset lock with private objects")
And delete our private modeset lock for pipeline.
Signed-off-by: James Qian Wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/Makefile | 1 +
.../display/komeda/komeda_pipeline_state.c| 142 ++
2 files changed, 143 insertions(+)
create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile
b/drivers/gpu/drm/arm/display/komeda/Makefile
index d593125236ae..62bd1bff66a3 100644
--- a/drivers/gpu/drm/arm/display/komeda/Makefile
+++ b/drivers/gpu/drm/arm/display/komeda/Makefile
@@ -9,6 +9,7 @@ komeda-y := \
komeda_dev.o \
komeda_format_caps.o \
komeda_pipeline.o \
+ komeda_pipeline_state.o \
komeda_framebuffer.o \
komeda_kms.o \
komeda_crtc.o \
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
new file mode 100644
index ..7ebab4fae567
--- /dev/null
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
+ * Author: James.Qian.Wang
+ *
+ */
+#include
+#include "komeda_dev.h"
+#include "komeda_kms.h"
+#include "komeda_pipeline.h"
+
+static inline bool is_switching_user(void *old, void *new)
+{
+ if (!old || !new)
+ return false;
+
+ return old != new;
+}
+
+struct komeda_pipeline_state *
+komeda_pipeline_get_state(struct komeda_pipeline *pipe,
+ struct drm_atomic_state *state)
+{
+ struct drm_private_state *priv_st;
+
+ priv_st = drm_atomic_get_private_obj_state(state, &pipe->obj);
+ if (IS_ERR(priv_st))
+ return ERR_CAST(priv_st);
+
+ return priv_to_pipe_st(priv_st);
+}
+
+/* Assign pipeline for crtc */
+struct komeda_pipeline_state *
+komeda_pipeline_get_state_and_set_crtc(struct komeda_pipeline *pipe,
+ struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+ struct komeda_pipeline_state *st;
+
+ st = komeda_pipeline_get_state(pipe, state);
+ if (IS_ERR(st))
+ return st;
+
+ if (is_switching_user(crtc, st->crtc)) {
+ DRM_DEBUG_ATOMIC("CRTC%d required pipeline%d is busy.\n",
+drm_crtc_index(crtc), pipe->id);
+ return ERR_PTR(-EBUSY);
+ }
+
+ /* pipeline only can be disabled when the it is free or unused */
+ if (!crtc && st->active_comps) {
+ DRM_DEBUG_ATOMIC("Disabling a busy pipeline:%d.\n", pipe->id);
+ return ERR_PTR(-EBUSY);
+ }
+
+ st->crtc = crtc;
+
+ if (crtc) {
+ struct komeda_crtc_state *kcrtc_st;
+
+ kcrtc_st = to_kcrtc_st(drm_atomic_get_new_crtc_state(state,
+crtc));
+
+ kcrtc_st->active_pipes |= BIT(pipe->id);
+ kcrtc_st->affected_pipes |= BIT(pipe->id);
+ }
+ return st;
+}
+
+static struct komeda_component_state *
+komeda_component_get_state(struct komeda_component *c,
+ struct drm_atomic_state *state)
+{
+ struct drm_private_state *priv_st;
+
+ WARN_ON(!drm_modeset_is_locked(&c->pipeline->obj.lock));
+
+ priv_st = drm_atomic_get_private_obj_state(state, &c->obj);
+ if (IS_ERR(priv_st))
+ return ERR_CAST(priv_st);
+
+ return priv_to_comp_st(priv_st);
+}
+
+/**
+ * komeda_component_get_state_and_set_user()
+ *
+ * @c: component to get state and set user
+ * @state: global atomic state
+ * @user: direct user, the binding user
+ * @crtc: the CRTC user, the big boss :)
+ *
+ * This function accepts two users:
+ * - The direct user: can be plane/crtc/wb_connector depends on component
+ * - The big boss (CRTC)
+ * CRTC is the big boss (the final user), because all component resources
+ * eventually will be assigned to CRTC, like the layer will be binding to
+ * kms_plane, but kms plane will be binding to a CRTC eventually.
+ *
+ * The big boss (CRTC) is for pipeline assignment, since &komeda_component
isn't
+ * independent and can be assigned to CRTC freely, but belongs to a specific
+ * pipeline, only pipeline can be shared between crtc, and pipeline as a whole
+ * (include all the internal components) assigned to a specific CRTC.
+ *
+ * So when set a user to komeda_component, need first to check the status of
+ * component->pipeline to see if the pipeline is
[PATCH v2 3/5] drm/komeda: Initialize komeda component as drm private object
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 modeset lock with private objects")
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_kms.c | 3 +-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 2 +-
.../arm/display/komeda/komeda_private_obj.c | 220 --
3 files changed, 208 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 4adc6a3104c9..7d7fb5013464 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -179,6 +179,7 @@ struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev
*mdev)
drm_irq_uninstall(drm);
cleanup_mode_config:
drm_mode_config_cleanup(drm);
+ komeda_kms_cleanup_private_objs(kms);
free_kms:
kfree(kms);
return ERR_PTR(err);
@@ -193,7 +194,7 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
drm_dev_unregister(drm);
drm_irq_uninstall(drm);
component_unbind_all(mdev->dev, drm);
- komeda_kms_cleanup_private_objs(mdev);
+ komeda_kms_cleanup_private_objs(kms);
drm_mode_config_cleanup(drm);
drm->dev_private = NULL;
drm_dev_put(drm);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 0faeeac2765a..06394716367b 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -107,7 +107,7 @@ int komeda_kms_add_crtcs(struct komeda_kms_dev *kms, struct
komeda_dev *mdev);
int komeda_kms_add_planes(struct komeda_kms_dev *kms, struct komeda_dev *mdev);
int komeda_kms_add_private_objs(struct komeda_kms_dev *kms,
struct komeda_dev *mdev);
-void komeda_kms_cleanup_private_objs(struct komeda_dev *mdev);
+void komeda_kms_cleanup_private_objs(struct komeda_kms_dev *kms);
void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
struct komeda_events *evts);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
index f1c9e3fefa86..a54878cbd6e4 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
@@ -7,6 +7,188 @@
#include "komeda_dev.h"
#include "komeda_kms.h"
+static void
+komeda_component_state_reset(struct komeda_component_state *st)
+{
+ st->binding_user = NULL;
+ st->affected_inputs = st->active_inputs;
+ st->active_inputs = 0;
+ st->changed_active_inputs = 0;
+}
+
+static struct drm_private_state *
+komeda_layer_atomic_duplicate_state(struct drm_private_obj *obj)
+{
+ struct komeda_layer_state *st;
+
+ st = kmemdup(obj->state, sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return NULL;
+
+ komeda_component_state_reset(&st->base);
+ __drm_atomic_helper_private_obj_duplicate_state(obj, &st->base.obj);
+
+ return &st->base.obj;
+}
+
+static void
+komeda_layer_atomic_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+ struct komeda_layer_state *st = to_layer_st(priv_to_comp_st(state));
+
+ kfree(st);
+}
+
+static const struct drm_private_state_funcs komeda_layer_obj_funcs = {
+ .atomic_duplicate_state = komeda_layer_atomic_duplicate_state,
+ .atomic_destroy_state = komeda_layer_atomic_destroy_state,
+};
+
+static int komeda_layer_obj_add(struct komeda_kms_dev *kms,
+ struct komeda_layer *layer)
+{
+ struct komeda_layer_state *st;
+
+ st = kzalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+
+ st->base.component = &layer->base;
+ drm_atomic_private_obj_init(&kms->base, &layer->base.obj, &st->base.obj,
+ &komeda_layer_obj_funcs);
+ return 0;
+}
+
+static struct drm_private_state *
+komeda_compiz_atomic_duplicate_state(struct drm_private_obj *obj)
+{
+ struct komeda_compiz_state *st;
+
+ st = kmemdup(obj->state, sizeof(*st), GFP_KERNEL);
+ if (!st)
+ return NULL;
+
+ komeda_component_state_reset(&st->base);
+ __drm_atomic_helper_private_obj_duplicate_state(obj, &st->base.obj);
+
+ return &st->base.obj;
+}
+
+static void
+komeda_compiz_atomic_destroy_state(struct drm_private_obj *obj,
+ struct drm_private_state *state)
+{
+ kfree(to_compiz_st(priv_to_comp_st(state)));
+}
+
+static const struct drm_private_state_funcs komeda_compiz_obj_f
[PATCH v2 5/5] drm/komeda: Add komeda_plane/plane_helper_funcs
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 will be handled in crtc->flush.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_plane.c | 128 ++
1 file changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 0a4953a9a909..af51f0cc9c16 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -10,7 +10,82 @@
#include "komeda_dev.h"
#include "komeda_kms.h"
+static int
+komeda_plane_init_data_flow(struct drm_plane_state *st,
+ struct komeda_data_flow_cfg *dflow)
+{
+ struct drm_framebuffer *fb = st->fb;
+
+ memset(dflow, 0, sizeof(*dflow));
+
+ dflow->blending_zorder = st->zpos;
+
+ /* if format doesn't have alpha, fix blend mode to PIXEL_NONE */
+ dflow->pixel_blend_mode = fb->format->has_alpha ?
+ st->pixel_blend_mode : DRM_MODE_BLEND_PIXEL_NONE;
+ dflow->layer_alpha = st->alpha >> 8;
+
+ dflow->out_x = st->crtc_x;
+ dflow->out_y = st->crtc_y;
+ dflow->out_w = st->crtc_w;
+ dflow->out_h = st->crtc_h;
+
+ dflow->in_x = st->src_x >> 16;
+ dflow->in_y = st->src_y >> 16;
+ dflow->in_w = st->src_w >> 16;
+ dflow->in_h = st->src_h >> 16;
+
+ return 0;
+}
+
+int komeda_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct komeda_plane *kplane = to_kplane(plane);
+ struct komeda_plane_state *kplane_st = to_kplane_st(state);
+ struct komeda_layer *layer = kplane->layer;
+ struct drm_crtc_state *crtc_st;
+ struct komeda_crtc *kcrtc;
+ struct komeda_crtc_state *kcrtc_st;
+ struct komeda_data_flow_cfg dflow;
+ int err;
+
+ if (!state->crtc || !state->fb)
+ return 0;
+
+ crtc_st = drm_atomic_get_crtc_state(state->state, state->crtc);
+ if (!crtc_st->enable) {
+ DRM_DEBUG_ATOMIC("Cannot update plane on a disabled CRTC.\n");
+ return -EINVAL;
+ }
+
+ /* crtc is inactive, skip the resource assignment */
+ if (!crtc_st->active)
+ return 0;
+
+ kcrtc = to_kcrtc(state->crtc);
+ kcrtc_st = to_kcrtc_st(crtc_st);
+
+ err = komeda_plane_init_data_flow(state, &dflow);
+ if (err)
+ return err;
+
+ err = komeda_build_layer_data_flow(layer, kplane_st, kcrtc_st, &dflow);
+
+ return err;
+}
+
+/* plane doesn't represent a real HW, so there is no HW update for plane.
+ * komeda handles all the HW update in crtc->atomic_flush
+ */
+void komeda_plane_atomic_update(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+}
+
static const struct drm_plane_helper_funcs komeda_plane_helper_funcs = {
+ .atomic_check = komeda_plane_atomic_check,
+ .atomic_update = komeda_plane_atomic_update,
};
static void komeda_plane_destroy(struct drm_plane *plane)
@@ -20,7 +95,60 @@ static void komeda_plane_destroy(struct drm_plane *plane)
kfree(to_kplane(plane));
}
+static void komeda_plane_reset(struct drm_plane *plane)
+{
+ struct komeda_plane_state *state;
+ struct komeda_plane *kplane = to_kplane(plane);
+
+ if (plane->state)
+ __drm_atomic_helper_plane_destroy_state(plane->state);
+
+ kfree(plane->state);
+ plane->state = NULL;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (state) {
+ state->base.rotation = DRM_MODE_ROTATE_0;
+ state->base.pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
+ state->base.alpha = DRM_BLEND_ALPHA_OPAQUE;
+ state->base.zpos = kplane->layer->base.id;
+ plane->state = &state->base;
+ plane->state->plane = plane;
+ }
+}
+
+static struct drm_plane_state *
+komeda_plane_atomic_duplicate_state(struct drm_plane *plane)
+{
+ struct komeda_plane_state *new;
+
+ if (WARN_ON(!plane->state))
+ return NULL;
+
+ new = kzalloc(sizeof(*new), GFP_KERNEL);
+ if (!new)
+ return NULL;
+
+ __drm_atomic_helper_plane_duplicate_state(plane, &new->base);
+
+ return &new->base;
+}
+
+static void
+komeda_plane_atomic_destroy_state(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ __drm_atomic_helper_plane_destroy_state(state);
+ kfree(to_kplane_st(state));
+}
+
static const struct drm_plane_funcs komeda_plane_funcs = {
+ .update_plane = drm_at
[PATCH v2 4/5] drm/komeda: Add komeda_build_layer_data_flow
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 komeda_data_flow_cfg
- Add a function komeda_component_validate_private to replace the MACRO
component_validate_private
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/komeda/komeda_pipeline.h | 24 ++
.../display/komeda/komeda_pipeline_state.c| 266 +-
2 files changed, 289 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index c30a790d0712..16d7ae891e81 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -278,6 +278,22 @@ struct komeda_timing_ctrlr_state {
struct komeda_component_state base;
};
+/* Why define A separated structure but not use plane_state directly ?
+ * 1. Komeda supports layer_split which means a plane_state can be split and
+ *handled by two layers, one layer only handle half of plane image.
+ * 2. Fix up the user properties according to HW's capabilities, like user
+ *set rotation to R180, but HW only supports REFLECT_X+Y. the rot here is
+ *after drm_rotation_simplify()
+ */
+struct komeda_data_flow_cfg {
+ struct komeda_component_output input;
+ u16 in_x, in_y, in_w, in_h;
+ u32 out_x, out_y, out_w, out_h;
+ u32 rot;
+ int blending_zorder;
+ u8 pixel_blend_mode, layer_alpha;
+};
+
/** struct komeda_pipeline_funcs */
struct komeda_pipeline_funcs {
/* dump_register: Optional, dump registers to seq_file */
@@ -382,4 +398,12 @@ komeda_component_add(struct komeda_pipeline *pipe,
void komeda_component_destroy(struct komeda_dev *mdev,
struct komeda_component *c);
+struct komeda_plane_state;
+struct komeda_crtc_state;
+
+int komeda_build_layer_data_flow(struct komeda_layer *layer,
+struct komeda_plane_state *kplane_st,
+struct komeda_crtc_state *kcrtc_st,
+struct komeda_data_flow_cfg *dflow);
+
#endif /* _KOMEDA_PIPELINE_H_*/
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index 7ebab4fae567..74d25e542103 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -8,6 +8,7 @@
#include "komeda_dev.h"
#include "komeda_kms.h"
#include "komeda_pipeline.h"
+#include "komeda_framebuffer.h"
static inline bool is_switching_user(void *old, void *new)
{
@@ -83,6 +84,18 @@ komeda_component_get_state(struct komeda_component *c,
return priv_to_comp_st(priv_st);
}
+static struct komeda_component_state *
+komeda_component_get_old_state(struct komeda_component *c,
+ struct drm_atomic_state *state)
+{
+ struct drm_private_state *priv_st;
+
+ priv_st = drm_atomic_get_old_private_obj_state(state, &c->obj);
+ if (priv_st)
+ return priv_to_comp_st(priv_st);
+ return NULL;
+}
+
/**
* komeda_component_get_state_and_set_user()
*
@@ -108,7 +121,7 @@ komeda_component_get_state(struct komeda_component *c,
* CRTC. if the pipeline is busy (assigned to another CRTC), even the required
* component is free, the component still cannot be assigned to the direct
user.
*/
-struct komeda_component_state *
+static struct komeda_component_state *
komeda_component_get_state_and_set_user(struct komeda_component *c,
struct drm_atomic_state *state,
void *user,
@@ -140,3 +153,254 @@ komeda_component_get_state_and_set_user(struct
komeda_component *c,
return st;
}
+
+static void
+komeda_component_add_input(struct komeda_component_state *state,
+ struct komeda_component_output *input,
+ int idx)
+{
+ struct komeda_component *c = state->component;
+
+ WARN_ON((idx < 0 || idx >= c->max_active_inputs));
+
+ /* since the inputs[i] is only valid when it is active. So if a input[i]
+* is a newly enabled input which switches from disable to enable, then
+* the old inputs[i] is undefined (NOT zeroed), we can not rely on
+* memcmp, but directly mark it changed
+*/
+ if (!has_bit(idx, state->affected_inputs) ||
+ memcmp(&state->inputs[idx], input, sizeof(*input))) {
+ memcpy(&state->inputs[idx], input, sizeof(*input));
+ state->changed_active_inputs |= BIT(idx);
+ }
+ state->active_inputs |= BIT(idx);
+ state->affected_inp
[PATCH v2 00/11] Implement komeda DRM-Crtc
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_display_data_flow drm/komeda: Add komeda_release_unclaimed_resources drm/komeda: Add komeda_crtc_atomic_flush drm/komeda: Add komeda_crtc_mode_valid/fixup drm/komeda: Add komeda_crtc_prepare/unprepare drm/komeda: Add komeda_crtc_atomic_enable/disable drm/komeda: Add komeda_crtc_vblank_enable/disable drm/komeda: Add komeda_crtc_funcs drm/komeda: Add komeda_kms_check drm/komeda: Add sysfs attribute: core_id and config_id drm/komeda: Expose bus_width to Komeda-CORE .../drm/arm/display/include/malidp_product.h | 12 + .../gpu/drm/arm/display/komeda/d71/d71_dev.c | 54 +++ .../gpu/drm/arm/display/komeda/komeda_crtc.c | 385 +- .../gpu/drm/arm/display/komeda/komeda_dev.c | 50 +++ .../gpu/drm/arm/display/komeda/komeda_dev.h | 34 ++ .../gpu/drm/arm/display/komeda/komeda_drv.c | 7 + .../gpu/drm/arm/display/komeda/komeda_kms.c | 36 +- .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 + .../drm/arm/display/komeda/komeda_pipeline.h | 14 + .../display/komeda/komeda_pipeline_state.c| 203 - 10 files changed, 790 insertions(+), 8 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 02/11] drm/komeda: Add komeda_release_unclaimed_resources
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 still needs to release/disable the
unclaimed pipeline resources.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 27 +
.../drm/arm/display/komeda/komeda_pipeline.h | 3 +
.../display/komeda/komeda_pipeline_state.c| 58 +++
3 files changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 7ca9bc8ef725..a250ab824155 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -14,6 +14,32 @@
#include "komeda_dev.h"
#include "komeda_kms.h"
+/* crtc_atomic_check is the final check stage, so beside build a display data
+ * pipeline according the crtc_state, but still needs to release/disable the
+ * unclaimed pipeline resources.
+ */
+static int
+komeda_crtc_atomic_check(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ struct komeda_crtc *kcrtc = to_kcrtc(crtc);
+ struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(state);
+ int err;
+
+ if (state->active) {
+ err = komeda_build_display_data_flow(kcrtc, kcrtc_st);
+ if (err)
+ return err;
+ }
+
+ /* release unclaimed pipeline resources */
+ err = komeda_release_unclaimed_resources(kcrtc->master, kcrtc_st);
+ if (err)
+ return err;
+
+ return 0;
+}
+
void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
struct komeda_events *evts)
{
@@ -33,6 +59,7 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
}
struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
+ .atomic_check = komeda_crtc_atomic_check,
};
static const struct drm_crtc_funcs komeda_crtc_funcs = {
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 22ad4dfc3e8d..54b646128760 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -409,4 +409,7 @@ int komeda_build_layer_data_flow(struct komeda_layer *layer,
int komeda_build_display_data_flow(struct komeda_crtc *kcrtc,
struct komeda_crtc_state *kcrtc_st);
+int komeda_release_unclaimed_resources(struct komeda_pipeline *pipe,
+ struct komeda_crtc_state *kcrtc_st);
+
#endif /* _KOMEDA_PIPELINE_H_*/
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index 6a481508624f..6797be630529 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -31,6 +31,18 @@ komeda_pipeline_get_state(struct komeda_pipeline *pipe,
return priv_to_pipe_st(priv_st);
}
+struct komeda_pipeline_state *
+komeda_pipeline_get_new_state(struct komeda_pipeline *pipe,
+ struct drm_atomic_state *state)
+{
+ struct drm_private_state *priv_st;
+
+ priv_st = drm_atomic_get_new_private_obj_state(state, &pipe->obj);
+ if (priv_st)
+ return priv_to_pipe_st(priv_st);
+ return NULL;
+}
+
/* Assign pipeline for crtc */
struct komeda_pipeline_state *
komeda_pipeline_get_state_and_set_crtc(struct komeda_pipeline *pipe,
@@ -478,3 +490,49 @@ int komeda_build_display_data_flow(struct komeda_crtc
*kcrtc,
return 0;
}
+
+void komeda_pipeline_unbound_components(struct komeda_pipeline *pipe,
+ struct komeda_pipeline_state *new)
+{
+ struct drm_atomic_state *drm_st = new->obj.state;
+ struct komeda_pipeline_state *old = priv_to_pipe_st(pipe->obj.state);
+ struct komeda_component_state *c_st;
+ struct komeda_component *c;
+ u32 disabling_comps, id;
+
+ WARN_ON(!old);
+
+ disabling_comps = (~new->active_comps) & old->active_comps;
+
+ /* unbound all disabling component */
+ dp_for_each_set_bit(id, disabling_comps) {
+ c = komeda_pipeline_get_component(pipe, id);
+ c_st = komeda_component_get_state_and_set_user(c,
+ drm_st, NULL, new->crtc);
+ WARN_ON(IS_ERR(c_st));
+ }
+}
+
+/* release unclaimed pipeline resource */
+int komeda_release_unclaimed_resources(struct komeda_pipeline *pipe,
+ struct komeda_crtc_state *kcrtc_st)
+{
+ struct drm_atomic_state *drm_st = kcrtc_st->base.stat
[PATCH v2 01/11] drm/komeda: Add komeda_build_display_data_flow
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: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/komeda/komeda_pipeline.h | 3 +
.../display/komeda/komeda_pipeline_state.c| 76 ++-
2 files changed, 78 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 16d7ae891e81..22ad4dfc3e8d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -400,10 +400,13 @@ void komeda_component_destroy(struct komeda_dev *mdev,
struct komeda_plane_state;
struct komeda_crtc_state;
+struct komeda_crtc;
int komeda_build_layer_data_flow(struct komeda_layer *layer,
struct komeda_plane_state *kplane_st,
struct komeda_crtc_state *kcrtc_st,
struct komeda_data_flow_cfg *dflow);
+int komeda_build_display_data_flow(struct komeda_crtc *kcrtc,
+ struct komeda_crtc_state *kcrtc_st);
#endif /* _KOMEDA_PIPELINE_H_*/
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index 74d25e542103..6a481508624f 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -344,7 +344,7 @@ komeda_compiz_set_input(struct komeda_compiz *compiz,
return 0;
}
-int
+static int
komeda_compiz_validate(struct komeda_compiz *compiz,
struct komeda_crtc_state *state,
struct komeda_data_flow_cfg *dflow)
@@ -382,6 +382,53 @@ komeda_compiz_validate(struct komeda_compiz *compiz,
return 0;
}
+static int
+komeda_improc_validate(struct komeda_improc *improc,
+ struct komeda_crtc_state *kcrtc_st,
+ struct komeda_data_flow_cfg *dflow)
+{
+ struct drm_crtc *crtc = kcrtc_st->base.crtc;
+ struct komeda_component_state *c_st;
+ struct komeda_improc_state *st;
+
+ c_st = komeda_component_get_state_and_set_user(&improc->base,
+ kcrtc_st->base.state, crtc, crtc);
+ if (IS_ERR(c_st))
+ return PTR_ERR(c_st);
+
+ st = to_improc_st(c_st);
+
+ st->hsize = dflow->in_w;
+ st->vsize = dflow->in_h;
+
+ komeda_component_add_input(&st->base, &dflow->input, 0);
+ komeda_component_set_output(&dflow->input, &improc->base, 0);
+
+ return 0;
+}
+
+static int
+komeda_timing_ctrlr_validate(struct komeda_timing_ctrlr *ctrlr,
+struct komeda_crtc_state *kcrtc_st,
+struct komeda_data_flow_cfg *dflow)
+{
+ struct drm_crtc *crtc = kcrtc_st->base.crtc;
+ struct komeda_timing_ctrlr_state *st;
+ struct komeda_component_state *c_st;
+
+ c_st = komeda_component_get_state_and_set_user(&ctrlr->base,
+ kcrtc_st->base.state, crtc, crtc);
+ if (IS_ERR(c_st))
+ return PTR_ERR(c_st);
+
+ st = to_ctrlr_st(c_st);
+
+ komeda_component_add_input(&st->base, &dflow->input, 0);
+ komeda_component_set_output(&dflow->input, &ctrlr->base, 0);
+
+ return 0;
+}
+
int komeda_build_layer_data_flow(struct komeda_layer *layer,
struct komeda_plane_state *kplane_st,
struct komeda_crtc_state *kcrtc_st,
@@ -404,3 +451,30 @@ int komeda_build_layer_data_flow(struct komeda_layer
*layer,
return err;
}
+
+/* build display output data flow, the data path is:
+ * compiz -> improc -> timing_ctrlr
+ */
+int komeda_build_display_data_flow(struct komeda_crtc *kcrtc,
+ struct komeda_crtc_state *kcrtc_st)
+{
+ struct komeda_pipeline *master = kcrtc->master;
+ struct komeda_data_flow_cfg m_dflow; /* master data flow */
+ int err;
+
+ memset(&m_dflow, 0, sizeof(m_dflow));
+
+ err = komeda_compiz_validate(master->compiz, kcrtc_st, &m_dflow);
+ if (err)
+ return err;
+
+ err = komeda_improc_validate(master->improc, kcrtc_st, &m_dflow);
+ if (err)
+ return err;
+
+ err = komeda_timing_ctrlr_validate(master->ctrlr, kcrtc_st, &m_dflow);
+ if (err)
+ return err;
+
+ return 0;
+}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 03/11] drm/komeda: Add komeda_crtc_atomic_flush
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 | 11 ++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 33 +
.../gpu/drm/arm/display/komeda/komeda_dev.h | 3 ++
.../drm/arm/display/komeda/komeda_pipeline.h | 5 +++
.../display/komeda/komeda_pipeline_state.c| 37 +++
5 files changed, 89 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index afc13d3b3afc..74aab4f23ea0 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -241,6 +241,16 @@ static int d71_disable_irq(struct komeda_dev *mdev)
return 0;
}
+static void d71_flush(struct komeda_dev *mdev,
+ int master_pipe, u32 active_pipes)
+{
+ struct d71_dev *d71 = mdev->chip_data;
+ u32 reg_offset = (master_pipe == 0) ?
+GCU_CONFIG_VALID0 : GCU_CONFIG_VALID1;
+
+ malidp_write32(d71->gcu_addr, reg_offset, GCU_CONFIG_CVAL);
+}
+
static int d71_reset(struct d71_dev *d71)
{
u32 __iomem *gcu = d71->gcu_addr;
@@ -457,6 +467,7 @@ static struct komeda_dev_funcs d71_chip_funcs = {
.irq_handler= d71_irq_handler,
.enable_irq = d71_enable_irq,
.disable_irq= d71_disable_irq,
+ .flush = d71_flush,
};
struct komeda_dev_funcs *
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index a250ab824155..95d8f2bcd523 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -58,8 +58,41 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
DRM_DEBUG("FLIP Done.\n");
}
+static void
+komeda_crtc_do_flush(struct drm_crtc *crtc,
+struct drm_crtc_state *old)
+{
+ struct komeda_crtc *kcrtc = to_kcrtc(crtc);
+ struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(crtc->state);
+ struct komeda_dev *mdev = kcrtc->base.dev->dev_private;
+ struct komeda_pipeline *master = kcrtc->master;
+
+ DRM_DEBUG_ATOMIC("CRTC%d_FLUSH: active_pipes: 0x%x, affected: 0x%x.\n",
+drm_crtc_index(crtc),
+kcrtc_st->active_pipes, kcrtc_st->affected_pipes);
+
+ /* step 1: update the pipeline/component state to HW */
+ if (has_bit(master->id, kcrtc_st->affected_pipes))
+ komeda_pipeline_update(master, old->state);
+
+ /* step 2: notify the HW to kickoff the update */
+ mdev->funcs->flush(mdev, master->id, kcrtc_st->active_pipes);
+}
+
+static void
+komeda_crtc_atomic_flush(struct drm_crtc *crtc,
+struct drm_crtc_state *old)
+{
+ /* commit with modeset will be handled in enable/disable */
+ if (drm_atomic_crtc_needs_modeset(crtc->state))
+ return;
+
+ komeda_crtc_do_flush(crtc, old);
+}
+
struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
.atomic_check = komeda_crtc_atomic_check,
+ .atomic_flush = komeda_crtc_atomic_flush,
};
static const struct drm_crtc_funcs komeda_crtc_funcs = {
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index 8eae2620ce77..0bd38bdf0518 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -106,6 +106,9 @@ struct komeda_dev_funcs {
/** @dump_register: Optional, dump registers to seq_file */
void (*dump_register)(struct komeda_dev *mdev, struct seq_file *seq);
+ /** @flush: Notify the HW to flush or kickoff the update */
+ void (*flush)(struct komeda_dev *mdev,
+ int master_pipe, u32 active_pipes);
};
/**
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
index 54b646128760..3d7a9ee550b2 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
@@ -412,4 +412,9 @@ int komeda_build_display_data_flow(struct komeda_crtc
*kcrtc,
int komeda_release_unclaimed_resources(struct komeda_pipeline *pipe,
struct komeda_crtc_state *kcrtc_st);
+void komeda_pipeline_disable(struct komeda_pipeline *pipe,
+struct drm_atomic_state *old_state);
+void komeda_pipeline_update(struct komeda_pipeline *pipe,
+ struct drm_atomic_state *old_state);
+
#endif /* _KOMEDA_PIPELINE_H_*/
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
b/drivers/gpu/drm/arm/display
[PATCH v2 09/11] drm/komeda: Add komeda_kms_check
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/drm/arm/display/komeda/komeda_kms.c | 30 ++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 7d7fb5013464..337e6fddead0 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -95,9 +95,37 @@ static const struct drm_mode_config_helper_funcs
komeda_mode_config_helpers = {
.atomic_commit_tail = komeda_kms_commit_tail,
};
+static int komeda_kms_check(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_st, *new_crtc_st;
+ int i, err;
+
+ err = drm_atomic_helper_check_modeset(dev, state);
+ if (err)
+ return err;
+
+ /* komeda need to re-calculate resource assumption in every commit
+* so need to add all affected_planes (even unchanged) to
+* drm_atomic_state.
+*/
+ for_each_oldnew_crtc_in_state(state, crtc, old_crtc_st, new_crtc_st, i)
{
+ err = drm_atomic_add_affected_planes(state, crtc);
+ if (err)
+ return err;
+ }
+
+ err = drm_atomic_helper_check_planes(dev, state);
+ if (err)
+ return err;
+
+ return 0;
+}
+
static const struct drm_mode_config_funcs komeda_mode_config_funcs = {
.fb_create = komeda_fb_create,
- .atomic_check = drm_atomic_helper_check,
+ .atomic_check = komeda_kms_check,
.atomic_commit = drm_atomic_helper_commit,
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 04/11] drm/komeda: Add komeda_crtc_mode_valid/fixup
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)
---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 52 +++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 95d8f2bcd523..7e0bf78da733 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -90,9 +90,61 @@ komeda_crtc_atomic_flush(struct drm_crtc *crtc,
komeda_crtc_do_flush(crtc, old);
}
+static enum drm_mode_status
+komeda_crtc_mode_valid(struct drm_crtc *crtc, const struct drm_display_mode *m)
+{
+ struct komeda_dev *mdev = crtc->dev->dev_private;
+ struct komeda_crtc *kcrtc = to_kcrtc(crtc);
+ struct komeda_pipeline *master = kcrtc->master;
+ long mode_clk, pxlclk;
+
+ if (m->flags & DRM_MODE_FLAG_INTERLACE)
+ return MODE_NO_INTERLACE;
+
+ /* main clock/AXI clk must be faster than pxlclk*/
+ mode_clk = m->clock * 1000;
+ pxlclk = clk_round_rate(master->pxlclk, mode_clk);
+ if (pxlclk != mode_clk) {
+ DRM_DEBUG_ATOMIC("pxlclk doesn't support %ld Hz\n", mode_clk);
+
+ return MODE_NOCLOCK;
+ }
+
+ if (clk_round_rate(mdev->mclk, mode_clk) < pxlclk) {
+ DRM_DEBUG_ATOMIC("mclk can't satisfy the requirement of %s-clk:
%ld.\n",
+m->name, pxlclk);
+
+ return MODE_CLOCK_HIGH;
+ }
+
+ if (clk_round_rate(master->aclk, mode_clk) < pxlclk) {
+ DRM_DEBUG_ATOMIC("aclk can't satisfy the requirement of %s-clk:
%ld.\n",
+m->name, pxlclk);
+
+ return MODE_CLOCK_HIGH;
+ }
+
+ return MODE_OK;
+}
+
+static bool komeda_crtc_mode_fixup(struct drm_crtc *crtc,
+ const struct drm_display_mode *m,
+ struct drm_display_mode *adjusted_mode)
+{
+ struct komeda_crtc *kcrtc = to_kcrtc(crtc);
+ struct komeda_pipeline *master = kcrtc->master;
+ long mode_clk = m->clock * 1000;
+
+ adjusted_mode->clock = clk_round_rate(master->pxlclk, mode_clk) / 1000;
+
+ return true;
+}
+
struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
.atomic_check = komeda_crtc_atomic_check,
.atomic_flush = komeda_crtc_atomic_flush,
+ .mode_valid = komeda_crtc_mode_valid,
+ .mode_fixup = komeda_crtc_mode_fixup,
};
static const struct drm_crtc_funcs komeda_crtc_funcs = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 06/11] drm/komeda: Add komeda_crtc_atomic_enable/disable
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 +-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
.../drm/arm/display/komeda/komeda_pipeline.h | 3 +
.../display/komeda/komeda_pipeline_state.c| 32 ++
4 files changed, 139 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index ef4c3ee2a688..9b370e1232e2 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -51,7 +51,7 @@ u32 komeda_calc_mclk(struct komeda_crtc_state *kcrtc_st)
* 1. adjust display operation mode.
* 2. enable needed clk
*/
-int
+static int
komeda_crtc_prepare(struct komeda_crtc *kcrtc)
{
struct komeda_dev *mdev = kcrtc->base.dev->dev_private;
@@ -107,7 +107,7 @@ komeda_crtc_prepare(struct komeda_crtc *kcrtc)
return err;
}
-int
+static int
komeda_crtc_unprepare(struct komeda_crtc *kcrtc)
{
struct komeda_dev *mdev = kcrtc->base.dev->dev_private;
@@ -157,9 +157,28 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
if (events & KOMEDA_EVENT_EOW)
DRM_DEBUG("EOW.\n");
- /* will handle it with crtc->flush */
- if (events & KOMEDA_EVENT_FLIP)
- DRM_DEBUG("FLIP Done.\n");
+ if (events & KOMEDA_EVENT_FLIP) {
+ unsigned long flags;
+ struct drm_pending_vblank_event *event;
+
+ spin_lock_irqsave(&crtc->dev->event_lock, flags);
+ if (kcrtc->disable_done) {
+ complete_all(kcrtc->disable_done);
+ kcrtc->disable_done = NULL;
+ } else if (crtc->state->event) {
+ event = crtc->state->event;
+ /*
+* Consume event before notifying drm core that flip
+* happened.
+*/
+ crtc->state->event = NULL;
+ drm_crtc_send_vblank_event(crtc, event);
+ } else {
+ DRM_WARN("CRTC[%d]: FLIP happen but no pending
commit.\n",
+drm_crtc_index(&kcrtc->base));
+ }
+ spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+ }
}
static void
@@ -183,6 +202,81 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
mdev->funcs->flush(mdev, master->id, kcrtc_st->active_pipes);
}
+static void
+komeda_crtc_atomic_enable(struct drm_crtc *crtc,
+ struct drm_crtc_state *old)
+{
+ komeda_crtc_prepare(to_kcrtc(crtc));
+ drm_crtc_vblank_on(crtc);
+ komeda_crtc_do_flush(crtc, old);
+}
+
+static void
+komeda_crtc_atomic_disable(struct drm_crtc *crtc,
+ struct drm_crtc_state *old)
+{
+ struct komeda_crtc *kcrtc = to_kcrtc(crtc);
+ struct komeda_crtc_state *old_st = to_kcrtc_st(old);
+ struct komeda_dev *mdev = crtc->dev->dev_private;
+ struct komeda_pipeline *master = kcrtc->master;
+ struct completion *disable_done = &crtc->state->commit->flip_done;
+ struct completion temp;
+ int timeout;
+
+ DRM_DEBUG_ATOMIC("CRTC%d_DISABLE: active_pipes: 0x%x, affected:
0x%x.\n",
+drm_crtc_index(crtc),
+old_st->active_pipes, old_st->affected_pipes);
+
+ if (has_bit(master->id, old_st->active_pipes))
+ komeda_pipeline_disable(master, old->state);
+
+ /* crtc_disable has two scenarios according to the state->active switch.
+* 1. active -> inactive
+*this commit is a disable commit. and the commit will be finished
+*or done after the disable operation. on this case we can directly
+*use the crtc->state->event to tracking the HW disable operation.
+* 2. active -> active
+*the crtc->commit is not for disable, but a modeset operation when
+*crtc is active, such commit actually has been completed by 3
+*DRM operations:
+*crtc_disable, update_planes(crtc_flush), crtc_enable
+*so on this case the crtc->commit is for the whole process.
+*we can not use it for tracing the disable, we need a temporary
+*flip_done for tracing the disable. and crtc->state->event for
+*the crtc_enable operation.
+*That's also the reason why skip modeset commit in
+*komeda_crtc_atomic_flush()
+*/
+ if (crtc->state->active) {
+ struct komeda_pipeline_state *pipe_st;
+ /* clear the old active_comps to zero */
+ pipe_st = komeda_pipeline_
[PATCH v2 08/11] drm/komeda: Add komeda_crtc_funcs
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 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index e19ba9468d31..7adda663b956 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -347,6 +347,47 @@ struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
.mode_fixup = komeda_crtc_mode_fixup,
};
+static void komeda_crtc_reset(struct drm_crtc *crtc)
+{
+ struct komeda_crtc_state *state;
+
+ if (crtc->state)
+ __drm_atomic_helper_crtc_destroy_state(crtc->state);
+
+ kfree(to_kcrtc_st(crtc->state));
+ crtc->state = NULL;
+
+ state = kzalloc(sizeof(*state), GFP_KERNEL);
+ if (state) {
+ crtc->state = &state->base;
+ crtc->state->crtc = crtc;
+ }
+}
+
+static struct drm_crtc_state *
+komeda_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
+{
+ struct komeda_crtc_state *old = to_kcrtc_st(crtc->state);
+ struct komeda_crtc_state *new;
+
+ new = kzalloc(sizeof(*new), GFP_KERNEL);
+ if (!new)
+ return NULL;
+
+ __drm_atomic_helper_crtc_duplicate_state(crtc, &new->base);
+
+ new->affected_pipes = old->active_pipes;
+
+ return &new->base;
+}
+
+static void komeda_crtc_atomic_destroy_state(struct drm_crtc *crtc,
+struct drm_crtc_state *state)
+{
+ __drm_atomic_helper_crtc_destroy_state(state);
+ kfree(to_kcrtc_st(state));
+}
+
static int komeda_crtc_vblank_enable(struct drm_crtc *crtc)
{
struct komeda_dev *mdev = crtc->dev->dev_private;
@@ -365,6 +406,13 @@ static void komeda_crtc_vblank_disable(struct drm_crtc
*crtc)
}
static const struct drm_crtc_funcs komeda_crtc_funcs = {
+ .gamma_set = drm_atomic_helper_legacy_gamma_set,
+ .destroy= drm_crtc_cleanup,
+ .set_config = drm_atomic_helper_set_config,
+ .page_flip = drm_atomic_helper_page_flip,
+ .reset = komeda_crtc_reset,
+ .atomic_duplicate_state = komeda_crtc_atomic_duplicate_state,
+ .atomic_destroy_state = komeda_crtc_atomic_destroy_state,
.enable_vblank = komeda_crtc_vblank_enable,
.disable_vblank = komeda_crtc_vblank_disable,
};
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 05/11] drm/komeda: Add komeda_crtc_prepare/unprepare
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 (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_dev.c | 32 ++
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 104 ++
.../gpu/drm/arm/display/komeda/komeda_dev.c | 2 +
.../gpu/drm/arm/display/komeda/komeda_dev.h | 26 +
4 files changed, 164 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 74aab4f23ea0..2fb29aea9f69 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -241,6 +241,37 @@ static int d71_disable_irq(struct komeda_dev *mdev)
return 0;
}
+static int to_d71_opmode(int core_mode)
+{
+ switch (core_mode) {
+ case KOMEDA_MODE_DISP0:
+ return DO0_ACTIVE_MODE;
+ case KOMEDA_MODE_DISP1:
+ return DO1_ACTIVE_MODE;
+ case KOMEDA_MODE_DUAL_DISP:
+ return DO01_ACTIVE_MODE;
+ case KOMEDA_MODE_INACTIVE:
+ return INACTIVE_MODE;
+ default:
+ WARN(1, "Unknown operation mode");
+ return INACTIVE_MODE;
+ }
+}
+
+static int d71_change_opmode(struct komeda_dev *mdev, int new_mode)
+{
+ struct d71_dev *d71 = mdev->chip_data;
+ u32 opmode = to_d71_opmode(new_mode);
+ int ret;
+
+ malidp_write32_mask(d71->gcu_addr, BLK_CONTROL, 0x7, opmode);
+
+ ret = dp_wait_cond(((malidp_read32(d71->gcu_addr, BLK_CONTROL) & 0x7)
== opmode),
+ 100, 1000, 1);
+
+ return ret > 0 ? 0 : -ETIMEDOUT;
+}
+
static void d71_flush(struct komeda_dev *mdev,
int master_pipe, u32 active_pipes)
{
@@ -467,6 +498,7 @@ static struct komeda_dev_funcs d71_chip_funcs = {
.irq_handler= d71_irq_handler,
.enable_irq = d71_enable_irq,
.disable_irq= d71_disable_irq,
+ .change_opmode = d71_change_opmode,
.flush = d71_flush,
};
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 7e0bf78da733..ef4c3ee2a688 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -40,6 +40,110 @@ komeda_crtc_atomic_check(struct drm_crtc *crtc,
return 0;
}
+u32 komeda_calc_mclk(struct komeda_crtc_state *kcrtc_st)
+{
+ unsigned long mclk = kcrtc_st->base.adjusted_mode.clock * 1000;
+
+ return mclk;
+}
+
+/* For active a crtc, mainly need two parts of preparation
+ * 1. adjust display operation mode.
+ * 2. enable needed clk
+ */
+int
+komeda_crtc_prepare(struct komeda_crtc *kcrtc)
+{
+ struct komeda_dev *mdev = kcrtc->base.dev->dev_private;
+ struct komeda_pipeline *master = kcrtc->master;
+ struct komeda_crtc_state *kcrtc_st = to_kcrtc_st(kcrtc->base.state);
+ unsigned long pxlclk_rate = kcrtc_st->base.adjusted_mode.clock * 1000;
+ u32 new_mode;
+ int err;
+
+ mutex_lock(&mdev->lock);
+
+ new_mode = mdev->dpmode | BIT(master->id);
+ if (WARN_ON(new_mode == mdev->dpmode)) {
+ err = 0;
+ goto unlock;
+ }
+
+ err = mdev->funcs->change_opmode(mdev, new_mode);
+ if (err) {
+ DRM_ERROR("failed to change opmode: 0x%x -> 0x%x.\n,",
+ mdev->dpmode, new_mode);
+ goto unlock;
+ }
+
+ mdev->dpmode = new_mode;
+ /* Only need to enable mclk on single display mode, but no need to
+* enable mclk it on dual display mode, since the dual mode always
+* switch from single display mode, the mclk already enabled, no need
+* to enable it again.
+*/
+ if (new_mode != KOMEDA_MODE_DUAL_DISP) {
+ err = clk_set_rate(mdev->mclk, komeda_calc_mclk(kcrtc_st));
+ if (err)
+ DRM_ERROR("failed to set mclk.\n");
+ err = clk_prepare_enable(mdev->mclk);
+ if (err)
+ DRM_ERROR("failed to enable mclk.\n");
+ }
+
+ err = clk_prepare_enable(master->aclk);
+ if (err)
+ DRM_ERROR("failed to enable axi clk for pipe%d.\n", master->id);
+ err = clk_set_rate(master->pxlclk, pxlclk_rate);
+ if (err)
+ DRM_ERROR("failed to set pxlclk for pipe%d\n", master->id);
+ err = clk_prepare_enable(master->pxlclk);
+ if (err)
+ DRM_ERROR("failed to enable pxl clk for pipe%d.\n", master->id);
+
+unlock:
+ mutex_unlock(&mdev->lock);
+
+ return err;
+}
+
+int
+komeda_crtc_unprepare(struct komeda_crtc *kcrtc)
+{
+
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
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 without the datasheet for the panels > > > > > > > > > you're > > > > > > > > > trying to submit. > > > > > > > > > > > > > > > > The panel bound with Sitronix ST7701 IC > > > > > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > > > > > > > > > > > > > It's the controller, not the panel > > > > > > > > > > > > As I said before, the datasheet of that panel doesn't have any > > > > > > information except electrical characteristics and used IC which is > > > > > > ST7701. > > > > > > > > > > > > I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 > > > > > > please find the attachment for the same. > > > > > > > > > > > > Here is some more details of the same. > > > > > > > > > > > > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erobbing/x300/x300.dtsi#L81 > > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > > matches timings for > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > > > Where did you get the timings from then? > > > > > > > > You mean drm_mode timings, the same panel with RGB available in > > > > panel-simple[1], and dsi driver in Mailing list[2] and actual DSI > > > > sequence commands from BSP[3] > > > > > > > > [1] > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > > [3] > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > > > So you had no reliable source for the timings then? How do you know if > > > all your patches that are timing related are right then? > > > > I don't understand your point, or may be I confused with many links > > that I attached in previous mail. > > > > 1. Patch for same panel timings are already in Mainline that was > > tested on one of the board. [1] > > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > > > Do you think the above two points are not valid sources? > > fyi, the panel datasheet attached in above mail has timing information. Do you have a page number? maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/11] drm/komeda: Add komeda_crtc_vblank_enable/disable
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 +++
.../gpu/drm/arm/display/komeda/komeda_dev.h | 3 +++
3 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 2fb29aea9f69..f517ab0ceae9 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -241,6 +241,15 @@ static int d71_disable_irq(struct komeda_dev *mdev)
return 0;
}
+static void d71_on_off_vblank(struct komeda_dev *mdev, int master_pipe, bool
on)
+{
+ struct d71_dev *d71 = mdev->chip_data;
+ struct d71_pipeline *pipe = d71->pipes[master_pipe];
+
+ malidp_write32_mask(pipe->dou_addr, BLK_IRQ_MASK,
+ DOU_IRQ_PL0, on ? DOU_IRQ_PL0 : 0);
+}
+
static int to_d71_opmode(int core_mode)
{
switch (core_mode) {
@@ -498,6 +507,7 @@ static struct komeda_dev_funcs d71_chip_funcs = {
.irq_handler= d71_irq_handler,
.enable_irq = d71_enable_irq,
.disable_irq= d71_disable_irq,
+ .on_off_vblank = d71_on_off_vblank,
.change_opmode = d71_change_opmode,
.flush = d71_flush,
};
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 9b370e1232e2..e19ba9468d31 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -347,7 +347,26 @@ struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
.mode_fixup = komeda_crtc_mode_fixup,
};
+static int komeda_crtc_vblank_enable(struct drm_crtc *crtc)
+{
+ struct komeda_dev *mdev = crtc->dev->dev_private;
+ struct komeda_crtc *kcrtc = to_kcrtc(crtc);
+
+ mdev->funcs->on_off_vblank(mdev, kcrtc->master->id, true);
+ return 0;
+}
+
+static void komeda_crtc_vblank_disable(struct drm_crtc *crtc)
+{
+ struct komeda_dev *mdev = crtc->dev->dev_private;
+ struct komeda_crtc *kcrtc = to_kcrtc(crtc);
+
+ mdev->funcs->on_off_vblank(mdev, kcrtc->master->id, false);
+}
+
static const struct drm_crtc_funcs komeda_crtc_funcs = {
+ .enable_vblank = komeda_crtc_vblank_enable,
+ .disable_vblank = komeda_crtc_vblank_disable,
};
int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index 1ad1f6e49854..8acd25afb3e9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -103,6 +103,9 @@ struct komeda_dev_funcs {
int (*enable_irq)(struct komeda_dev *mdev);
/** @disable_irq: disable irq */
int (*disable_irq)(struct komeda_dev *mdev);
+ /** @on_off_vblank: notify HW to on/off vblank */
+ void (*on_off_vblank)(struct komeda_dev *mdev,
+ int master_pipe, bool on);
/** @dump_register: Optional, dump registers to seq_file */
void (*dump_register)(struct komeda_dev *mdev, struct seq_file *seq);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 10/11] drm/komeda: Add sysfs attribute: core_id and config_id
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/komeda/komeda_dev.c | 48 +++
.../gpu/drm/arm/display/komeda/komeda_dev.h | 2 +
.../gpu/drm/arm/display/komeda/komeda_drv.c | 7 +++
4 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h
b/drivers/gpu/drm/arm/display/include/malidp_product.h
index b35fc5db866b..1053b11352eb 100644
--- a/drivers/gpu/drm/arm/display/include/malidp_product.h
+++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
@@ -20,4 +20,16 @@
/* Mali-display product IDs */
#define MALIDP_D71_PRODUCT_ID 0x0071
+union komeda_config_id {
+ struct {
+ __u32 max_line_sz:16,
+ n_pipelines:2,
+ n_scalers:2, /* number of scalers per pipeline */
+ n_layers:3, /* number of layers per pipeline */
+ n_richs:3, /* number of rich layers per pipeline */
+ reserved_bits:6;
+ };
+ __u32 value;
+};
+
#endif /* _MALIDP_PRODUCT_H_ */
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
index 7152f2c08e01..9e017ce89d69 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c
@@ -53,6 +53,46 @@ static void komeda_debugfs_init(struct komeda_dev *mdev)
mdev, &komeda_register_fops);
}
+static ssize_t
+core_id_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct komeda_dev *mdev = dev_to_mdev(dev);
+
+ return snprintf(buf, PAGE_SIZE, "0x%08x\n", mdev->chip.core_id);
+}
+static DEVICE_ATTR_RO(core_id);
+
+static ssize_t
+config_id_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+ struct komeda_dev *mdev = dev_to_mdev(dev);
+ struct komeda_pipeline *pipe = mdev->pipelines[0];
+ union komeda_config_id config_id = {0,};
+ int i;
+
+ config_id.max_line_sz = pipe->layers[0]->hsize_in.end;
+ config_id.n_pipelines = mdev->n_pipelines;
+ config_id.n_scalers = pipe->n_scalers;
+ config_id.n_layers = pipe->n_layers;
+ config_id.n_richs = 0;
+ for (i = 0; i < pipe->n_layers; i++) {
+ if (pipe->layers[i]->layer_type == KOMEDA_FMT_RICH_LAYER)
+ config_id.n_richs++;
+ }
+ return snprintf(buf, PAGE_SIZE, "0x%08x\n", config_id.value);
+}
+static DEVICE_ATTR_RO(config_id);
+
+static struct attribute *komeda_sysfs_entries[] = {
+ &dev_attr_core_id.attr,
+ &dev_attr_config_id.attr,
+ NULL,
+};
+
+static struct attribute_group komeda_sysfs_attr_group = {
+ .attrs = komeda_sysfs_entries,
+};
+
static int komeda_parse_pipe_dt(struct komeda_dev *mdev, struct device_node
*np)
{
struct komeda_pipeline *pipe;
@@ -201,6 +241,12 @@ struct komeda_dev *komeda_dev_create(struct device *dev)
goto err_cleanup;
}
+ err = sysfs_create_group(&dev->kobj, &komeda_sysfs_attr_group);
+ if (err) {
+ DRM_ERROR("create sysfs group failed.\n");
+ goto err_cleanup;
+ }
+
#ifdef CONFIG_DEBUG_FS
komeda_debugfs_init(mdev);
#endif
@@ -218,6 +264,8 @@ void komeda_dev_destroy(struct komeda_dev *mdev)
struct komeda_dev_funcs *funcs = mdev->funcs;
int i;
+ sysfs_remove_group(&dev->kobj, &komeda_sysfs_attr_group);
+
#ifdef CONFIG_DEBUG_FS
debugfs_remove_recursive(mdev->debugfs_root);
#endif
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
index 8acd25afb3e9..0c3e32b596d9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.h
@@ -190,4 +190,6 @@ d71_identify(u32 __iomem *reg, struct komeda_chip_info
*chip);
struct komeda_dev *komeda_dev_create(struct device *dev);
void komeda_dev_destroy(struct komeda_dev *mdev);
+struct komeda_dev *dev_to_mdev(struct device *dev);
+
#endif /*_KOMEDA_DEV_H_*/
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index 2bdd189b041d..0285fd37a016 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -17,6 +17,13 @@ struct komeda_drv {
struct komeda_kms_dev *kms;
};
+struct komeda_dev *dev_to_mdev(struct device *dev)
+{
+ struct komeda_drv *mdrv = dev_get_drvdata(dev);
+
+ return mdrv ? mdrv->mdev : NULL;
+}
+
static void komeda_unbind(struct device *dev)
{
struct komeda_drv *mdrv = dev_get_drvdata(dev);
--
2.17.1
_
[PATCH v2 11/11] drm/komeda: Expose bus_width to Komeda-CORE
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/display/komeda/komeda_kms.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index f517ab0ceae9..a6ca3ff16fef 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -518,6 +518,7 @@ d71_identify(u32 __iomem *reg_base, struct komeda_chip_info
*chip)
chip->arch_id = malidp_read32(reg_base, GLB_ARCH_ID);
chip->core_id = malidp_read32(reg_base, GLB_CORE_ID);
chip->core_info = malidp_read32(reg_base, GLB_CORE_INFO);
+ chip->bus_width = D71_BUS_WIDTH_16_BYTES;
return &d71_chip_funcs;
}
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 337e6fddead0..ed54beaee2f9 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -21,10 +21,10 @@ static int komeda_gem_cma_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
- u32 alignment = 16; /* TODO get alignment from dev */
+ struct komeda_dev *mdev = dev->dev_private;
+ u32 pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
- args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8),
- alignment);
+ args->pitch = ALIGN(pitch, mdev->chip.bus_width);
return drm_gem_cma_dumb_create_internal(file, dev, args);
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
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 > > > > > > > > trying to submit. > > > > > > > > > > > > > > The panel bound with Sitronix ST7701 IC > > > > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > > > > > > > > > > > It's the controller, not the panel > > > > > > > > > > As I said before, the datasheet of that panel doesn't have any > > > > > information except electrical characteristics and used IC which is > > > > > ST7701. > > > > > > > > > > I have one more panel, which is from Bananapi, S070WV20-CT16 ICN621 > > > > > please find the attachment for the same. > > > > > > > > > > Here is some more details of the same. > > > > > > > > > > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erobbing/x300/x300.dtsi#L81 > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > matches timings for > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > Where did you get the timings from then? > > > > > > You mean drm_mode timings, the same panel with RGB available in > > > panel-simple[1], and dsi driver in Mailing list[2] and actual DSI > > > sequence commands from BSP[3] > > > > > > [1] > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > [3] > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > So you had no reliable source for the timings then? How do you know if > > all your patches that are timing related are right then? > > I don't understand your point, or may be I confused with many links > that I attached in previous mail. > > 1. Patch for same panel timings are already in Mainline that was > tested on one of the board. [1] > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > Do you think the above two points are not valid sources? I'm saying that the only valid source is the datasheet or a DSI analyzer. Maxmie -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 07/17] drm/sun4i: sun6i_mipi_dsi: Refactor vertical video start delay
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:41AM +0530, Jagan Teki wrote: > > > > > > > > > > Again, I cannot help you without the datasheet for the > > > > > > > > > > panels you're > > > > > > > > > > trying to submit. > > > > > > > > > > > > > > > > > > The panel bound with Sitronix ST7701 IC > > > > > > > > > http://www.startek-lcd.com/res/starteklcd/pdres/201705/20170512144242904.pdf > > > > > > > > > > > > > > > > It's the controller, not the panel > > > > > > > > > > > > > > As I said before, the datasheet of that panel doesn't have any > > > > > > > information except electrical characteristics and used IC which is > > > > > > > ST7701. > > > > > > > > > > > > > > I have one more panel, which is from Bananapi, S070WV20-CT16 > > > > > > > ICN621 > > > > > > > please find the attachment for the same. > > > > > > > > > > > > > > Here is some more details of the same. > > > > > > > > > > > > > > https://github.com/yesnoandor/x300/blob/master/kernel/arch/arm/boot/dts/erobbing/x300/x300.dtsi#L81 > > > > > > > https://github.com/wxzed/Raspberry_5MIPI_Display/blob/master/I2C_Slave/USER/main.c#L15 > > > > > > > > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/drivers/video/msm/mdss/mdss_i2c_interface.c#L152 > > > > > > > matches timings for > > > > > > > https://github.com/eliot-shao/qcom/blob/master/icn6211_cxn0102/kernel/arch/arm/boot/dts/qcom/dsi-mipi-2-rgb_1280p_video.dtsi#L20 > > > > > > > > > > > > > > https://github.com/zestroly/micromat/blob/master/test/raspberry/ICN6211.cpp#L169 > > > > > > > > > > > > Where did you get the timings from then? > > > > > > > > > > You mean drm_mode timings, the same panel with RGB available in > > > > > panel-simple[1], and dsi driver in Mailing list[2] and actual DSI > > > > > sequence commands from BSP[3] > > > > > > > > > > [1] > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/gpu/drm/panel/panel-simple.c?id=7ad8b41cd8f5c2842646d01cdd576663caee04a7 > > > > > [2] https://patchwork.kernel.org/patch/10680331/ > > > > > [3] > > > > > https://github.com/BPI-SINOVOIP/BPI-M64-bsp/blob/master/linux-sunxi/drivers/video/sunxi/disp2/disp/lcd/S070WV20_MIPI_RGB.c > > > > > > > > So you had no reliable source for the timings then? How do you know if > > > > all your patches that are timing related are right then? > > > > > > I don't understand your point, or may be I confused with many links > > > that I attached in previous mail. > > > > > > 1. Patch for same panel timings are already in Mainline that was > > > tested on one of the board. [1] > > > 2. Driver from AW, released bsp from BPI-M64-bsp [3] > > > > > > Do you think the above two points are not valid sources? > > > > fyi, the panel datasheet attached in above mail has timing information. > > Do you have a page number? Page 4 5.2 Interface Timings ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 02/15] drm/i915: Don't try to use the hardware frame counter with i965gm TV output
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 guesstimation method
> used on gen2.
>
> Note that the pipe timings generated by the TV encoder
> are also rather peculiar. Apparently the pipe wants to
> run at a much higher speed (related to the oversample
> clock somehow it seems) but during the vertical active
> period the TV encoder stalls the pipe every few lines
> to keep its speed in check. But once the vertical
> blanking period is reached the pipe gets to run at full
> speed. This means our vblank timestamp estimates are
> suspect. Fixing all that would require quite a bit
> more work. This simple fix at least avoids the nasty
> vblank timeouts that are happening currently.
>
> Curiously the frame counter works just fine on i945gm
> and gm45. I don't really understand what kind of mishap
> occurred with the hardware design on i965gm. Sadly
> I wasn't able to find any chicken bits etc. that would
> fix the frame counter :(
>
> v2: Move the zero vs. non-zero hw counter value handling
> into i915_get_vblank_counter() (Daniel)
> Use the per-crtc maximum exclusively, leaving the
> per-device maximum at zero
> v3: max_vblank_count not populated yet in intel_enable_pipe()
> use intel_crtc_max_vblank_count() instead
>
> Cc: sta...@vger.kernel.org
> Cc: Daniel Vetter
> Fixes: 51e31d49c890 ("drm/i915: Use generic vblank wait")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93782
> Signed-off-by: Ville Syrjälä
>
> fix# _slub_broken.S
^ some remnant
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_irq.c | 27 ++--
> drivers/gpu/drm/i915/intel_display.c | 48 +++-
> 2 files changed, 58 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index d447d7d508f4..ab2d4eefef18 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -822,11 +822,26 @@ static void i915_enable_asle_pipestat(struct
> drm_i915_private *dev_priv)
> static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> + const struct drm_display_mode *mode = &vblank->hwmode;
> i915_reg_t high_frame, low_frame;
> u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
> - const struct drm_display_mode *mode = &dev->vblank[pipe].hwmode;
> unsigned long irqflags;
>
> + /*
> + * On i965gm TV output the frame counter only works up to
> + * the point when we enable the TV encoder. After that the
> + * frame counter ceases to work and reads zero. We need a
> + * vblank wait before enabling the TV encoder and so we
> + * have to enable vblank interrupts while the frame counter
> + * is still in a working state. However the core vblank code
> + * does not like us returning non-zero frame counter values
> + * when we've told it that we don't have a working frame
> + * counter. Thus we must stop non-zero values leaking out.
> + */
> + if (!vblank->max_vblank_count)
> + return 0;
> +
> htotal = mode->crtc_htotal;
> hsync_start = mode->crtc_hsync_start;
> vbl_start = mode->crtc_vblank_start;
> @@ -4836,16 +4851,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> if (INTEL_GEN(dev_priv) >= 8)
> rps->pm_intrmsk_mbz |= GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
>
> - if (IS_GEN2(dev_priv)) {
> - /* Gen2 doesn't have a hardware frame counter */
> - dev->max_vblank_count = 0;
> - } else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
> - dev->max_vblank_count = 0x; /* full 32 bit counter */
> + if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
> dev->driver->get_vblank_counter = g4x_get_vblank_counter;
> - } else {
> + else if (INTEL_GEN(dev_priv) >= 3)
> dev->driver->get_vblank_counter = i915_get_vblank_counter;
> - dev->max_vblank_count = 0xff; /* only 24 bits of frame
> count */
> - }
>
> /*
>* Opt out of the vblank disable timer on everything except gen2.
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e9f4e22b2a4e..cb13eff78ad9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1754,6 +1754,35 @@ enum pipe intel_crtc_pch_transcoder(struct intel_crtc
> *crtc)
> return crtc->pipe;
> }
>
> +static u32 intel_crtc_max_vblank_count(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct drm_i
Re: [Intel-gfx] [PATCH 03/15] drm/i915/tv: Fix interlaced ysize calculation
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 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c > index 860f306a23ba..219a16d6dcc2 100644 > --- a/drivers/gpu/drm/i915/intel_tv.c > +++ b/drivers/gpu/drm/i915/intel_tv.c > @@ -1087,7 +1087,7 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > if (tv_mode->progressive) > ysize = tv_mode->nbr_end + 1; > else > - ysize = 2*tv_mode->nbr_end + 1; > + ysize = 2 * (tv_mode->nbr_end + 1); > > xpos += conn_state->tv.margins.left; > ypos += conn_state->tv.margins.top; > -- > 2.18.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/15] drm/i915/tv: Fix tv mode clocks
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 | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 219a16d6dcc2..dea24ef88763 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -636,7 +636,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "480p",
> - .clock = 107520,
> + .clock = 108000,
> .refresh= 59940,
> .oversample = TV_OVERSAMPLE_4X,
> .component_only = 1,
> @@ -660,7 +660,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "576p",
> - .clock = 107520,
> + .clock = 108000,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_4X,
> .component_only = 1,
> @@ -684,7 +684,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "720p@60Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 6,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -708,7 +708,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "720p@50Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -733,7 +733,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "1080i@50Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -759,7 +759,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "1080i@60Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 6,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -1114,7 +1114,7 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder,
> static const struct drm_display_mode reported_modes[] = {
> {
> .name = "NTSC 480i",
> - .clock = 107520,
> + .clock = 108000,
> .hdisplay = 1280,
> .hsync_start = 1368,
> .hsync_end = 1496,
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 05/15] drm/i915/tv: Store the TV oversampling factor in the TV mode
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 Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 42 ++---
> 1 file changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index dea24ef88763..96257b29d07c 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -307,7 +307,7 @@ struct tv_mode {
>
> u32 clock;
> u16 refresh; /* in millihertz (for precision) */
> - u32 oversample;
> + u8 oversample;
> u8 hsync_end;
> u16 hblank_start, hblank_end, htotal;
> bool progressive : 1, trilevel_sync : 1, component_only : 1;
> @@ -379,7 +379,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-M",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
>
> @@ -422,7 +422,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-443",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 4.43MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -464,7 +464,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-J",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> @@ -507,7 +507,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL-M",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> @@ -551,7 +551,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL-N",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> .hsync_end = 64, .hblank_end = 128,
> @@ -596,7 +596,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> .hsync_end = 64, .hblank_end = 142,
> @@ -638,7 +638,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "480p",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_4X,
> + .oversample = 4,
> .component_only = 1,
>
> .hsync_end = 64, .hblank_end = 122,
> @@ -662,7 +662,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "576p",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_4X,
> + .oversample = 4,
> .component_only = 1,
>
> .hsync_end = 64, .hblank_end = 139,
> @@ -686,7 +686,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "720p@60Hz",
> .clock = 148500,
> .refresh= 6,
> - .oversample = TV_OVERSAMPLE_2X,
> + .oversample = 2,
> .component_only = 1,
>
> .hsync_end = 80, .hblank_end = 300,
> @@ -710,7 +710,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "720p@50Hz",
> .clock = 148500,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_2X,
> + .oversample = 2,
> .component_only = 1,
>
> .hsync_end = 80, .hblank_en
Re: [PATCH 06/15] drm/i915/tv: Use bools where appropriate
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 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 96257b29d07c..72de154b8627 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -380,7 +380,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
>
> .hsync_end = 64, .hblank_end = 124,
> @@ -423,7 +423,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 4.43MHz */
> .hsync_end = 64, .hblank_end = 124,
> .hblank_start = 836, .htotal = 857,
> @@ -465,7 +465,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -508,7 +508,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -552,7 +552,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> .hsync_end = 64, .hblank_end = 128,
> .hblank_start = 844,.htotal = 863,
> @@ -597,7 +597,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> .hsync_end = 64, .hblank_end = 142,
> .hblank_start = 844, .htotal = 863,
> @@ -639,7 +639,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 4,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 64, .hblank_end = 122,
> .hblank_start = 842, .htotal = 857,
> @@ -663,7 +663,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 4,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 64, .hblank_end = 139,
> .hblank_start = 859, .htotal = 863,
> @@ -687,7 +687,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 6,
> .oversample = 2,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 80, .hblank_end = 300,
> .hblank_start = 1580, .htotal = 1649,
> @@ -711,7 +711,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 5,
> .oversample = 2,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 80, .hblank_end = 300,
> .hblank_start = 1580, .htotal = 1979,
> @@ -736,7 +736,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 5,
Re: [Intel-gfx] [PATCH 07/15] drm/i915/tv: Nuke silly 0 initialzation of xpos/ypos
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/i915/intel_tv.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c > index 72de154b8627..97a82878359f 100644 > --- a/drivers/gpu/drm/i915/intel_tv.c > +++ b/drivers/gpu/drm/i915/intel_tv.c > @@ -994,7 +994,7 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > const struct video_levels *video_levels; > const struct color_conversion *color_conversion; > bool burst_ena; > - int xpos = 0x0, ypos = 0x0; > + int xpos, ypos; > unsigned int xsize, ysize; > > if (!tv_mode) > @@ -1103,8 +1103,8 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > else > ysize = 2 * (tv_mode->nbr_end + 1); > > - xpos += conn_state->tv.margins.left; > - ypos += conn_state->tv.margins.top; > + xpos = conn_state->tv.margins.left; > + ypos = conn_state->tv.margins.top; > xsize -= (conn_state->tv.margins.left + > conn_state->tv.margins.right); > ysize -= (conn_state->tv.margins.top + > -- > 2.18.1 > > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Make igts for cross-driver stuff mandatory
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 Thu, Jan 17, 2019 at 12:38 PM Liviu Dudau > > > > wrote: > > > > > > > > > > On Wed, Jan 16, 2019 at 05:39:03PM +0100, 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 in the RFC discussions). > > > > > > > > > > > > - tests reorganized into subdirectories so that the i915-gem tests > > > > > > don't clog the main/shared tests directory anymore > > > > > > > > > > > > - quite a few more non-intel people > > > > > > contributing/reviewing/committing > > > > > > igt tests patches. > > > > > > > > > > > > I think this addresses all the concerns raised in the RFC > > > > > > discussions, > > > > > > and assuming there's enough Acks and no new issues that pop up, we > > > > > > can > > > > > > go ahead with this. > > > > > > > > > > > > 1: https://patchwork.kernel.org/patch/10648851/ > > > > > > Cc: Petri Latvala > > > > > > Cc: Arkadiusz Hiler > > > > > > Cc: Liviu Dudau > > > > > > Cc: Sean Paul > > > > > > Cc: Eric Anholt > > > > > > Cc: Alex Deucher > > > > > > Cc: Dave Airlie > > > > > > Signed-off-by: Daniel Vetter > > > > > > --- > > > > > > Documentation/gpu/drm-uapi.rst | 7 +++ > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > > > diff --git a/Documentation/gpu/drm-uapi.rst > > > > > > b/Documentation/gpu/drm-uapi.rst > > > > > > index a752aa561ea4..413915d6b7d2 100644 > > > > > > --- a/Documentation/gpu/drm-uapi.rst > > > > > > +++ b/Documentation/gpu/drm-uapi.rst > > > > > > @@ -238,6 +238,13 @@ DRM specific patterns. Note that ENOTTY has > > > > > > the slightly unintuitive meaning of > > > > > > Testing and validation > > > > > > == > > > > > > > > > > > > +Testing Requirements for userspace API > > > > > > +-- > > > > > > + > > > > > > +New cross-driver userspace interface extensions, like new IOCTL, > > > > > > new KMS > > > > > > +properties, new files in sysfs or anything else that constitutes > > > > > > an API change > > > > > > +need to have driver-agnostic testcases in IGT for that feature. > > > > > > > > > > From an aspirational point of view I am fine with this and you can > > > > > have > > > > > my Acked-by: Liviu Dudau . > > > > > > > > > > From a practical point of view I would like to see a matrix of KMS > > > > > APIs > > > > > that are being validated and the drivers that have been tested. > > > > > Otherwise, > > > > > the next person that comes and tries to add a new IOCTL, KMS property > > > > > or new > > > > > file in sysfs is going to discover that he has subscribed to a much > > > > > bigger > > > > > task of getting enough KMS drivers testable in the first place. > > > > > > > > This is what the _new_ features is about, no expectation to write > > > > tests for all the existing stuff. Although I think there's not really > > > > any big gaps in igt anymore, we do have at least some (rather rough > > > > and coarse in some case) test coverage for everything I think. Should > > > > this be clarified further? > > > > -Daniel > > > > > > > > > > I share a similar view to Liviu here. I think this new requirement > > > raises the bar more than you intended. > > > > > > By saying that all new features must be tested by igt, you're also > > > implying that a driver must run igt (at some basic level); before the > > > developers working on that driver can start trying to implement new > > > features. That puts an additional hurdle in the way of adding stuff > > > to KMS for people who aren't already using igt. > > > > > > I'm all for testing, and UAPI being well proven before we merge it, > > > and even for a central KMS test suite. However, when we (Arm Mali-DP > > > people) have tried to implement things in igt it's been a battle, > > > because of various built-in assumptions which it made. > > > > > > For example, most meaningful igt tests rely on CRC. Much of our HW > > > doesn't have CRC. CRC could be implemented in theory using writeback, > > > but that currently doesn't exist. That means you're effectively saying > > > that we (Arm) can't implement any new cross-device KMS features until > > > we've either: > > > > > > a) also implemented writeback-based CRC in igt OR > > > b) implemented the new feature in someone else's driver which does > > > support CRC. > > > > We didn't just pick crcs for lols (or because that's all intel > > supports), we picked it because it will work for both hw with crc
Re: [PATCH] drm/doc: Make igts for cross-driver stuff mandatory
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, > > > > > > > > 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 at 05:39:03PM +0100, 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 in the RFC discussions). > > > > > > > > > > > > > > - tests reorganized into subdirectories so that the i915-gem tests > > > > > > > don't clog the main/shared tests directory anymore > > > > > > > > > > > > > > - quite a few more non-intel people > > > > > > > contributing/reviewing/committing > > > > > > > igt tests patches. > > > > > > > > > > > > > > I think this addresses all the concerns raised in the RFC > > > > > > > discussions, > > > > > > > and assuming there's enough Acks and no new issues that pop up, > > > > > > > we can > > > > > > > go ahead with this. > > > > > > > > > > > > > > 1: https://patchwork.kernel.org/patch/10648851/ > > > > > > > Cc: Petri Latvala > > > > > > > Cc: Arkadiusz Hiler > > > > > > > Cc: Liviu Dudau > > > > > > > Cc: Sean Paul > > > > > > > Cc: Eric Anholt > > > > > > > Cc: Alex Deucher > > > > > > > Cc: Dave Airlie > > > > > > > Signed-off-by: Daniel Vetter > > > > > > > --- > > > > > > > Documentation/gpu/drm-uapi.rst | 7 +++ > > > > > > > 1 file changed, 7 insertions(+) > > > > > > > > > > > > > > diff --git a/Documentation/gpu/drm-uapi.rst > > > > > > > b/Documentation/gpu/drm-uapi.rst > > > > > > > index a752aa561ea4..413915d6b7d2 100644 > > > > > > > --- a/Documentation/gpu/drm-uapi.rst > > > > > > > +++ b/Documentation/gpu/drm-uapi.rst > > > > > > > @@ -238,6 +238,13 @@ DRM specific patterns. Note that ENOTTY has > > > > > > > the slightly unintuitive meaning of > > > > > > > Testing and validation > > > > > > > == > > > > > > > > > > > > > > +Testing Requirements for userspace API > > > > > > > +-- > > > > > > > + > > > > > > > +New cross-driver userspace interface extensions, like new IOCTL, > > > > > > > new KMS > > > > > > > +properties, new files in sysfs or anything else that constitutes > > > > > > > an API change > > > > > > > +need to have driver-agnostic testcases in IGT for that feature. > > > > > > > > > > > > From an aspirational point of view I am fine with this and you can > > > > > > have > > > > > > my Acked-by: Liviu Dudau . > > > > > > > > > > > > From a practical point of view I would like to see a matrix of KMS > > > > > > APIs > > > > > > that are being validated and the drivers that have been tested. > > > > > > Otherwise, > > > > > > the next person that comes and tries to add a new IOCTL, KMS > > > > > > property or new > > > > > > file in sysfs is going to discover that he has subscribed to a much > > > > > > bigger > > > > > > task of getting enough KMS drivers testable in the first place. > > > > > > > > > > This is what the _new_ features is about, no expectation to write > > > > > tests for all the existing stuff. Although I think there's not really > > > > > any big gaps in igt anymore, we do have at least some (rather rough > > > > > and coarse in some case) test coverage for everything I think. Should > > > > > this be clarified further? > > > > > -Daniel > > > > > > > > > > > > > I share a similar view to Liviu here. I think this new requirement > > > > raises the bar more than you intended. > > > > > > > > By saying that all new features must be tested by igt, you're also > > > > implying that a driver must run igt (at some basic level); before the > > > > developers working on that driver can start trying to implement new > > > > features. That puts an additional hurdle in the way of adding stuff > > > > to KMS for people who aren't already using igt. > > > > > > > > I'm all for testing, and UAPI being well proven before we merge it, > > > > and even for a central KMS test suite. However, when we (Arm Mali-DP > > > > people) have tried to implement things in igt it's been a battle, > > > > because of various built-in assumptions which it made. > > > > > > > > For example, most meaningful igt tests rely on CRC. Much of our HW > > > > doesn't have CRC. CRC could be implemented in theory using writeback, > > > > but that currently doesn't exist. That means you're effectively saying > > > > that we (Arm) can't implement any new cross-device KMS features until > > > > we've eit
[PATCH] drm/tegra: Provide fallback IOMMU domain geometry
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 needed
before any devices attach to it.
Work around this by falling back to a 32-bit address space for the IOMMU
domain geometry. This is guaranteed to always work on all generations of
Tegra and no known use-cases require more IOVA space than that.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 4b70ce664c41..8af61559d662 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -93,7 +93,7 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
if (iommu_present(&platform_bus_type)) {
u64 carveout_start, carveout_end, gem_start, gem_end;
- struct iommu_domain_geometry *geometry;
+ dma_addr_t start, end;
unsigned long order;
tegra->domain = iommu_domain_alloc(&platform_bus_type);
@@ -106,11 +106,21 @@ static int tegra_drm_load(struct drm_device *drm,
unsigned long flags)
if (err < 0)
goto domain;
- geometry = &tegra->domain->geometry;
- gem_start = geometry->aperture_start;
- gem_end = geometry->aperture_end - CARVEOUT_SZ;
+ start = tegra->domain->geometry.aperture_start;
+ end = tegra->domain->geometry.aperture_end;
+
+ /*
+* The ARM SMMU driver only sets up the geometry after the
+* domain has been attached to a device. In that case, make
+* sure to fallback to a reasonable default.
+*/
+ if (start == 0 && end == 0)
+ end = 0x;
+
+ gem_start = start;
+ gem_end = end - CARVEOUT_SZ;
carveout_start = gem_end + 1;
- carveout_end = geometry->aperture_end;
+ carveout_end = end;
order = __ffs(tegra->domain->pgsize_bitmap);
init_iova_domain(&tegra->carveout.domain, 1UL << order,
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 08/15] drm/i915/tv: Deobfuscate preferred mode selection
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.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 50 -
> 1 file changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 97a82878359f..54189080cfb1 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -860,6 +860,14 @@ intel_tv_mode_valid(struct drm_connector *connector,
> return MODE_CLOCK_RANGE;
> }
>
> +static int
> +intel_tv_mode_vdisplay(const struct tv_mode *tv_mode)
> +{
> + if (tv_mode->progressive)
> + return tv_mode->nbr_end + 1;
> + else
> + return 2 * (tv_mode->nbr_end + 1);
> +}
>
> static void
> intel_tv_get_config(struct intel_encoder *encoder,
> @@ -1098,10 +1106,7 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder,
> /* Filter ctl must be set before TV_WIN_SIZE */
> I915_WRITE(TV_FILTER_CTL_1, TV_AUTO_SCALE);
> xsize = tv_mode->hblank_start - tv_mode->hblank_end;
> - if (tv_mode->progressive)
> - ysize = tv_mode->nbr_end + 1;
> - else
> - ysize = 2 * (tv_mode->nbr_end + 1);
> + ysize = intel_tv_mode_vdisplay(tv_mode);
>
> xpos = conn_state->tv.margins.left;
> ypos = conn_state->tv.margins.top;
> @@ -1320,22 +1325,28 @@ static const struct input_res {
> {"1920x1080", 1920, 1080},
> };
>
> -/*
> - * Chose preferred mode according to line number of TV format
> - */
> +/* Choose preferred mode according to line number of TV format */
> +static bool
> +intel_tv_is_preferred_mode(const struct drm_display_mode *mode,
> +const struct tv_mode *tv_mode)
> +{
> + int vdisplay = intel_tv_mode_vdisplay(tv_mode);
> +
> + /* prefer 480 line modes for all SD TV modes */
> + if (vdisplay <= 576)
> + vdisplay = 480;
> +
> + return vdisplay == mode->vdisplay;
> +}
> +
> static void
> -intel_tv_choose_preferred_modes(const struct tv_mode *tv_mode,
> -struct drm_display_mode *mode_ptr)
> +intel_tv_set_mode_type(struct drm_display_mode *mode,
> +const struct tv_mode *tv_mode)
> {
> - if (tv_mode->nbr_end < 480 && mode_ptr->vdisplay == 480)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - else if (tv_mode->nbr_end > 480) {
> - if (tv_mode->progressive == true && tv_mode->nbr_end < 720) {
> - if (mode_ptr->vdisplay == 720)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - } else if (mode_ptr->vdisplay == 1080)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - }
> + mode->type = DRM_MODE_TYPE_DRIVER;
> +
> + if (intel_tv_is_preferred_mode(mode, tv_mode))
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> }
>
> static int
> @@ -1383,8 +1394,7 @@ intel_tv_get_modes(struct drm_connector *connector)
> tmp = div_u64(tmp, 100);
> mode_ptr->clock = (int) tmp;
>
> - mode_ptr->type = DRM_MODE_TYPE_DRIVER;
> - intel_tv_choose_preferred_modes(tv_mode, mode_ptr);
> + intel_tv_set_mode_type(mode_ptr, tv_mode);
> drm_mode_probed_add(connector, mode_ptr);
> count++;
> }
> --
> 2.18.1
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 09/15] drm/i915/tv: Use drm_mode_set_name() to name TV 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 Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 54189080cfb1..433f538261c1 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1313,16 +1313,15 @@ intel_tv_detect(struct drm_connector *connector,
> }
>
> static const struct input_res {
> - const char *name;
> - int w, h;
> + u16 w, h;
> } input_res_table[] = {
> - {"640x480", 640, 480},
> - {"800x600", 800, 600},
> - {"1024x768", 1024, 768},
> - {"1280x1024", 1280, 1024},
> - {"848x480", 848, 480},
> - {"1280x720", 1280, 720},
> - {"1920x1080", 1920, 1080},
> + { 640, 480 },
> + { 800, 600 },
> + { 1024, 768 },
> + { 1280, 1024 },
> + { 848, 480 },
> + { 1280, 720 },
> + { 1920, 1080 },
> };
>
> /* Choose preferred mode according to line number of TV format */
> @@ -1373,7 +1372,6 @@ intel_tv_get_modes(struct drm_connector *connector)
> mode_ptr = drm_mode_create(connector->dev);
> if (!mode_ptr)
> continue;
> - strlcpy(mode_ptr->name, input->name, DRM_DISPLAY_MODE_LEN);
>
> mode_ptr->hdisplay = hactive_s;
> mode_ptr->hsync_start = hactive_s + 1;
> @@ -1395,6 +1393,9 @@ intel_tv_get_modes(struct drm_connector *connector)
> mode_ptr->clock = (int) tmp;
>
> intel_tv_set_mode_type(mode_ptr, tv_mode);
> +
> + drm_mode_set_name(mode_ptr);
> +
> drm_mode_probed_add(connector, mode_ptr);
> count++;
> }
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
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 from hanging the box, but otherwise left it > > enabled. So if we make a policy change to also disable it anywhere > > where it doesn't work well (instead of not at all), there's a pile > > more platforms to switch. > > I think its best to just disable iommu for the igfx devices on these > platforms. Can you pick up Eric's patch and extend it with the list of > affected platforms? We've been discussing this again more actively since a few months ago, and the discussion is still ongoing internally. 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 not be using the iGFX device. So for some uses, the fact that the device (group) is assignable seems to be more important than the iGFX device to be working. I'm afraid that retroactively disabling the assignment for such an old platform might break those usage scenarios. By my quick reading of the code, there's no way for user to turn the iGFX DMAR on once the quirk disables it. I guess one solution would be to default to intel_iommu=igfx_off for platforms that are older than certain threshold. But still allow user to enable. But that then requires duplicating the PCI ID database into iommu code. I don't really have winning moves to present, but I'm open to hearing how we can avoid more damage than starting to default to intel_iommu=on did already. Regards, Joonas > > Thanks, > > Joerg ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 10/15] drm/i915/tv: Make TV mode autoselection actually useable
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 disagrees with it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 433f538261c1..32a8786fe0da 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1253,16 +1253,18 @@ static void intel_tv_find_better_format(struct
> drm_connector *connector)
> const struct tv_mode *tv_mode = intel_tv_mode_find(connector->state);
> int i;
>
> - if ((intel_tv->type == DRM_MODE_CONNECTOR_Component) ==
> - tv_mode->component_only)
> + /* Component supports everything so we can keep the current mode */
> + if (intel_tv->type == DRM_MODE_CONNECTOR_Component)
> return;
>
> + /* If the current mode is fine don't change it */
> + if (!tv_mode->component_only)
> + return;
>
> for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> - tv_mode = tv_modes + i;
> + tv_mode = &tv_modes[i];
>
> - if ((intel_tv->type == DRM_MODE_CONNECTOR_Component) ==
> - tv_mode->component_only)
> + if (!tv_mode->component_only)
> break;
> }
>
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
