Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1324966

Re: FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver

From Daniel Kurtz <djkurtz@chromium.org>
Newsgroups linux.kernel
Subject Re: FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver
Date 2016-02-03 07:50 +0100
Message-ID <qXZqh-6Mx-9@gated-at.bofh.it> (permalink)
References <qXYNA-6z9-19@gated-at.bofh.it> <qXYNA-6z9-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


> Hi Dan,
>
> Thanks for your comment.
> This solution looks good to me.
> I will change it as your suggestion.
>
> But, I have a question about 'mask out the provided *device virtual*
> address'.
> Are lower 16-bits (or 24-bits for JUMP op) of device virtual address the
> same as device physical address?

I'm not sure.  But I doubt it we can rely on this.
My guess would be that the ioremap only preserves the lower 12 bits
(4k page size).

> If not, we still need to pass in physical address into CMDQ driver.

Or, instead of the iommu/slot approach, we can just provide a
registration function for the gce driver.
Each gce consumer could then have a simple gce node, with no slot/address:

  mediatek,gce = <&gce>;

Then on probe, the gce consumer could pass in its (struct device *) to
gce_register_device().  gce_register_device() could then access the
device's of_node to extract its physical address range, and look up
its physical address in its table of per-soc of
"device_address:gce_subsys_address" entries.  If the physical address
is in a valid subsys ranges, the gce_register_device would cache the
subsys address, and an offset in a (struct gce_consumer).
gce_register_device() could then add this struct to a struct list_head
of gce_consumers, and finally return a pointer to it back to the
caller.

Later, the gce consumer could pass in ths (struct gce_consumer *) when
make gce calls, along with the *offset* (not the physical address or
virtual address) for the register that it wishes to access.  Then the
gce driver can simply use the gce_consumer->subsys entry to create a
gce address from the passed in offset.

This will keep the binding very simple, and would remove the need to
convert from device virtual to physical addresses by the gce consumer,
but require a little more per-gce-consumer setup.

-Dan

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver Horng-Shyang Liao <hs.liao@mediatek.com> - 2016-02-03 07:10 +0100
  Re: FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver Daniel Kurtz <djkurtz@chromium.org> - 2016-02-03 07:50 +0100
    Re: FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver Horng-Shyang Liao <hs.liao@mediatek.com> - 2016-02-03 09:10 +0100

csiph-web