linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: hs.liao@mediatek.com (Horng-Shyang Liao)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 3/3] CMDQ: Mediatek CMDQ driver
Date: Fri, 26 Feb 2016 17:00:30 +0800	[thread overview]
Message-ID: <1456477230.17841.2.camel@mtksdaap41> (raw)
In-Reply-To: <CAGS+omABD93f3X0pfiFgaxa9Lob2txkJfUUomUvs+hiRkxSuHw@mail.gmail.com>

On Wed, 2016-02-03 at 14:40 +0800, Daniel Kurtz wrote:
> > 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

Hi Dan,

When I try to implement this comment, I realize the only benefit from
this comment is to wrap physical address.

Recall from my previous reply: gce address = subsys + valid low bits.
So, CMDQ driver still need to do "(Base + offset) & valid mask" to get
gce valid low bits.
Current implementation let display driver do "base + offset".
This comment just transfers this calculation from display driver to CMDQ
driver.

However, this comment will let CMDQ interface (behavior) become more
complicated, e.g. gce_register_device(), struct gce_consumer, and int
cmdq_rec_write(struct cmdq_rec *handle, u32 value, struct gce_consumer
*consumer, u32 offset)

Do you think it is worth to do this effort to wrap physical address?

Thanks,
HS Liao

  parent reply	other threads:[~2016-02-26  9:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8A0FDEEF9DBBD140A3857422D81DA20F867B19FD@mtkmbs01n1>
2016-02-03  6:02 ` FW: [RFC 3/3] CMDQ: Mediatek CMDQ driver Horng-Shyang Liao
2016-02-03  6:40   ` Daniel Kurtz
2016-02-03  8:04     ` Horng-Shyang Liao
2016-02-26  9:00     ` Horng-Shyang Liao [this message]
2016-02-26 16:47       ` Daniel Kurtz
2016-01-20  5:14 [RFC 0/3] MT8173 CMDQ support hs.liao at mediatek.com
2016-01-20  5:14 ` [RFC 3/3] CMDQ: Mediatek CMDQ driver hs.liao at mediatek.com
2016-01-28  4:49   ` Daniel Kurtz
2016-01-29  7:39     ` Horng-Shyang Liao
2016-01-29  8:42       ` Daniel Kurtz
2016-01-29 12:24         ` Horng-Shyang Liao
2016-01-29 13:15           ` Daniel Kurtz
2016-02-01  2:04             ` Horng-Shyang Liao
2016-02-01  4:15               ` Daniel Kurtz
2016-02-01  6:20                 ` Horng-Shyang Liao
2016-02-01 10:22                   ` Daniel Kurtz
2016-02-02  6:48                     ` Horng-Shyang Liao
2016-02-02 16:21                       ` Daniel Kurtz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1456477230.17841.2.camel@mtksdaap41 \
    --to=hs.liao@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).