Quoting Rob Clark (2017-06-14 17:49:02)
> On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra
> wrote:
> > Buffer object specific resources like pages, domains, sg list
> > need not be protected with struct_mutex. They can be protected
> > with a buffer object level lock. This simplifies lockin
---
This is roughly based on Chris's suggestion, in particular the part
about using mutex_lock_nested(). It's not *exactly* the same, in
particular msm_obj->lock protects a bit more than just backing store
and we don't currently track a pin_count. (Instead we currently
keep pages pinned until the
Commit c0c0d9eeeb8d ("drm/msm: hdmi audio support") uses logical
OR operators to build up a value to be written in the
REG_HDMI_AUDIO_INFO0 and REG_HDMI_AUDIO_INFO1 registers when it
should have used bitwise operators.
Signed-off-by: Liviu Dudau
Fixes: c0c0d9eeeb8d ("drm/msm: hdmi audio support")
rob,
i tried using dsi_mgr_parse_dual_dsi , but dsi1 is not getting enabled for
some reason, may be TODO:apq8064 more when we use dual dsi in dts.
so i am trying without using dsi_mgr_parse_dual_dsi/dual dsi in dts
after modifying dsi_manager.c , now userspace is assuming as single display
for t
Hi Rob,
I can see how we can trigger the shrinker on objB while holding objA->lock. So,
the nested lock with class SHRINKER makes sense.
However, I’m trying to figure how the get_pages/vmap/fault path on an objA can
end up triggering the shrinker on objA itself. As objA itself would not be
purg
On Thu, Jun 15, 2017 at 5:59 PM, Susheelendra, Sushmita
wrote:
> Hi Rob,
>
> I can see how we can trigger the shrinker on objB while holding objA->lock.
> So, the nested lock with class SHRINKER makes sense.
> However, I’m trying to figure how the get_pages/vmap/fault path on an objA
> can end up
