> Sounds like things are progressing nicely for a while there, presumably
> until the next time the display is being refreshed.
>
> Would you be willing to try out the following work in progress:
> https://lore.kernel.org/linux-arm-msm/20200717001619.325317-1-bjorn.anders...@linaro.org/
I sure
On Wed 22 Jul 13:11 PDT 2020, Konrad Dybcio wrote:
> >Is the problem on SDM630 that when you write to SMR/S2CR the device
> >reboots? Or that when you start writing out the context bank
> >configuration that trips the display and the device reboots?
>
> I added some debug prints and the phone
>Is the problem on SDM630 that when you write to SMR/S2CR the device
>reboots? Or that when you start writing out the context bank
>configuration that trips the display and the device reboots?
I added some debug prints and the phone hangs after reaching the
seventh CB (with i=6) at
On Tue 21 Jul 09:20 PDT 2020, Konrad Dybcio wrote:
> >The current
> >focus has been on moving more of the SMMU specific bits into the
> >arm-smmu-qcom
> >implementation [1] and I think that is the right way to go.
>
> Pardon if I overlooked something obvious, but I can't seem to find a
> clean
>The current
>focus has been on moving more of the SMMU specific bits into the arm-smmu-qcom
>implementation [1] and I think that is the right way to go.
Pardon if I overlooked something obvious, but I can't seem to find a
clean way for implementing qcom,skip-init in arm-smmu-qcom, as neither
the
On Tue, Jul 21, 2020 at 05:04:11PM +0200, Konrad Dybcio wrote:
> So.. is this a no-no?
>
> I of course would like to omit this entirely, but SMMUs on sdm630 and
> friends are REALLY picky.. What seems to happen is that when the
> driver tries to do things the "standard" way, hypervisor decides to
So.. is this a no-no?
I of course would like to omit this entirely, but SMMUs on sdm630 and
friends are REALLY picky.. What seems to happen is that when the
driver tries to do things the "standard" way, hypervisor decides to
hang the platform or force a reboot. Not very usable.
This thing is
On Sat 04 Jul 06:09 PDT 2020, Will Deacon wrote:
> [Adding Bjorn, Jordan and John because I really don't want a bunch of
> different ways to tell the driver that the firmware is screwing things up]
>
Thanks Will.
> On Sat, Jul 04, 2020 at 02:28:09PM +0200, Konrad Dybcio wrote:
> > This adds
> It would probably be better to know _which_ context banks we shouldn't
> touch, no? Otherwise what happens to the others?
> Do we not need to worry about the SMRs as well?
This was mimicked from CAF (think [1]) and the SMMUs don't make the
hypervisor angry anymore, so I wouldn't be too picky
[Adding Bjorn, Jordan and John because I really don't want a bunch of
different ways to tell the driver that the firmware is screwing things up]
On Sat, Jul 04, 2020 at 02:28:09PM +0200, Konrad Dybcio wrote:
> This adds the downstream property required to support
> SMMUs on SDM630 and other
This adds the downstream property required to support
SMMUs on SDM630 and other platforms (the need for it
most likely depends on firmware configuration).
Signed-off-by: Konrad Dybcio
---
.../devicetree/bindings/iommu/arm,smmu.yaml | 10 ++
drivers/iommu/arm-smmu.c
11 matches
Mail list logo
