Re: [PATCH v4 08/21] dt-bindings: reserved-memory: Add qcom,ramoops binding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 7/2/2023 1:42 PM, Krzysztof Kozlowski wrote:
On 28/06/2023 17:01, Mukesh Ojha wrote:


On 6/28/2023 8:17 PM, Rob Herring wrote:
On Wed, Jun 28, 2023 at 6:36 AM Mukesh Ojha <quic_mojha@xxxxxxxxxxx> wrote:

Qualcomm ramoops minidump logger provide a means of storing
the ramoops data to some dynamically reserved memory instead
of traditionally implemented ramoops where the region should
be statically fixed ram region. Its device tree binding
would be exactly same as ramoops device tree binding and is
going to contain traditional ramoops frontend data and this
content will be collected via Qualcomm minidump infrastructure
provided from the boot firmware.

The big difference is if firmware is not deciding where this log
lives, then it doesn't need to be in DT. How does anything except the
kernel that allocates the log find the logs?

Yes, you are correct, firmware is not deciding where the logs lives
instead here, Kernel has reserved the region where the ramoops region
lives and later with the minidump registration where, physical
address/size/virtual address(for parsing) are passed and that is how
firmware is able to know and dump those region before triggering system
reset.

Your explanation does not justify storing all this in DT. Kernel can
allocate any memory it wishes, store there logs and pass the address to
the firmware. That's it, no need for DT.

If you go through the driver, you will know that what it does, is
just create platform device for actual ramoops driver to probe and to
provide this it needs exact set of parameters of input what original ramoops DT provides, we need to keep it in DT as maintaining this in
driver will not scale well with different size/parameter size
requirement for different targets.



A part of this registration code you can find in 11/21

I'm pretty sure I already said all this before.

Yes, you said this before but that's the reason i came up with vendor
ramoops instead of changing traditional ramoops binding.

That's unexpected conclusion. Adding more bindings is not the answer to
comment that it should not be in the DTS in the first place.

Please suggest, what is the other way being above text as requirement..

-- Mukesh

Best regards,
Krzysztof




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux