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

[Horng-Shyang Liao]

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 = <>;
> 
> 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,

This solution is better.
I will use it.
Thanks for your suggestion.

Thanks,
HS Liao

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

[Horng-Shyang Liao]

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 = <>;
> 
> 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,

This solution is better.
I will use it.
Thanks for your suggestion.

Thanks,
HS Liao

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

[Daniel Kurtz]

> 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 = <>;

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

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

[Horng-Shyang Liao]

On Wed, 2016-02-03 at 09:40 +0800, Cawa Cheng (鄭曄禧) wrote:
> 
> -Original Message-
> From: djku...@google.com [mailto:djku...@google.com] On Behalf Of Daniel Kurtz
> Sent: Wednesday, February 03, 2016 12:22 AM
> To: Hs Liao (廖宏祥)
> Cc: Rob Herring; Matthias Brugger; Sascha Hauer; open list:OPEN FIRMWARE 
> AND...; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
> moderated list:ARM/Mediatek SoC support; srv_heupstream; Sascha Hauer; 
> Philipp Zabel; Nicolas Boichat; CK Hu (胡俊光); Cawa Cheng (鄭曄禧); Bibby Hsieh 
> (謝濟遠); YT Shen (沈岳霆); Daoyuan Huang (黃道原); Damon Chu (朱峻賢); Josh-YC Liu 
> (劉育誠); Glory Hung (洪智瑋); Yong Wu (吴勇)
> Subject: Re: [RFC 3/3] CMDQ: Mediatek CMDQ driver
> 
> On Tue, Feb 2, 2016 at 2:48 PM, Horng-Shyang Liao  
> wrote:
> > On Mon, 2016-02-01 at 18:22 +0800, Daniel Kurtz wrote:
> >> On Mon, Feb 1, 2016 at 2:20 PM, Horng-Shyang Liao  
> >> wrote:
> >> > On Mon, 2016-02-01 at 12:15 +0800, Daniel Kurtz wrote:
> >> >> On Mon, Feb 1, 2016 at 10:04 AM, Horng-Shyang Liao 
> >> >>  wrote:
> >> >> >
> >> >> > On Fri, 2016-01-29 at 21:15 +0800, Daniel Kurtz wrote:
> >> >> > > On Fri, Jan 29, 2016 at 8:24 PM, Horng-Shyang Liao 
> >> >> > >  wrote:
> >> >> > > > On Fri, 2016-01-29 at 16:42 +0800, Daniel Kurtz wrote:
> >> >> > > >> On Fri, Jan 29, 2016 at 3:39 PM, Horng-Shyang Liao 
> >> >> > > >>  wrote:
> >> >> > > >> > Hi Dan,
> >> >> > > >> >
> >> >> > > >> > Many thanks for your comments and time.
> >> >> > > >> > I reply my plan inline.
> >> >> > > >> >
> >> >> > > >> >
> >> >> > > >> > On Thu, 2016-01-28 at 12:49 +0800, Daniel Kurtz wrote:
> >> >> > > >> >> Hi HS,
> >> >> > > >> >>
> >> >> > > >> >> Sorry for the delay.  It is hard to find time to review 
> >> >> > > >> >> a >3700 line driver :-o in detail
> >> >> > > >> >>
> >> >> > > >> >> Some review comments inline, although I still do not 
> >> >> > > >> >> completely understand how all that this driver does and how 
> >> >> > > >> >> it works.
> >> >> > > >> >> I'll try to find time to go through this driver in 
> >> >> > > >> >> detail again next time you post it for review.
> >> >> > > >> >>
> >> >> > > >> >> On Tue, Jan 19, 2016 at 9:14 PM,   
> >> >> > > >> >> wrote:
> >> >> > > >> >> > From: HS Liao 
> >> >> > > >> >> >
> >> >> > > >> >> > This patch is first version of Mediatek Command 
> >> >> > > >> >> > Queue(CMDQ) driver. The CMDQ is used to help 
> >> >> > > >> >> > read/write registers with critical time limitation, 
> >> >> > > >> >> > such as updating display configuration during the vblank. 
> >> >> > > >> >> > It controls Global Command Engine (GCE) hardware to achieve 
> >> >> > > >> >> > this requirement.
> >> >> > > >> >> > Currently, CMDQ only supports display related 
> >> >> > > >> >> > hardwares, but we expect it can be extended to other 
> >> >> > > >> >> > hardwares for future requirements.
> >> >> > > >> >> >
> >> >> > > >> >> > Signed-off-by: HS Liao 
> >> >> > > >> >>
> >> >> > > >> >> [snip]
> >> >> > > >> >>
> >> >> > > >> >> > diff --git a/drivers/soc/mediatek/mtk-cmdq.c 
> >> >> > > >> >> > b/drivers/soc/mediatek/mtk-cmdq.c new file mode 100644 
> >> >> > > >> >> > index 000..7570f00
> >> >> > > >> >> > --- /dev/null
> >> >> > > >> >> > +++ b/drivers/soc/mediatek/mtk-cmdq.c
> >> >> > > >
> >> >> > > > [snip]
> >> >> > > >
> >> >> > > >> >> > +static const struct cmdq_subsys g_subsys[] = {
> >> >> > > >> >> > +   {0x1400, 1, "MMSYS"},
> >> >> > > >> >> > +   {0x1401, 2, "DISP"},
> >> >> > > >> >> > +   {0x1402, 3, "DISP"},
> >> >> > > >> >>
> >> >> > > >> >> This isn't going to scale.  These addresses could be 
> >> >> > > >> >> different on different chips.
> >> >> > > >> >> Instead of a static table like this, we probably need 
> >> >> > > >> >> specify to the connection between gce and other devices 
> >> >> > > >> >> via devicetree phandles, and then use the phandles to 
> >> >> > > >> >> lookup the corresponding device address range.
> >> >> > > >> >
> >> >> > > >> > I will define them in device tree.
> >> >> > > >> > E.g.
> >> >> > > >> > cmdq {
> >> >> > > >> >   reg_domain = 0x1400, 0x1401, 0x1402 }
> >> >> > > >>
> >> >> > > >> The devicetree should only model hardware relationships, 
> >> >> > > >> not software considerations.
> >> >> > > >>
> >> >> > > >> Is the hardware constraint here for using gce with various 
> >> >> > > >> other hardware blocks?  I think we already model this by 
> >> >> > > >> only providing a gce phandle in the device tree nodes for 
> >> >> > > >> those devices that can use gce.
> >> >> > > >>
> >> >> > > >> Looking at the driver closer, as far as I can tell, the 
> >> >> > > >> whole subsys concept is a purely software abstraction, and 
> >> >> > > >> only used to debug the CMDQ_CODE_WRITE command.  In fact, 
> >> >> > > >> AFAICT, everything would work fine if we just completely 
> >> >> > > >> removed the 'subsys' concept, and just passed through the raw 
> >> >> > > >> address provided by the driver.
> >> 

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

[Horng-Shyang Liao]

On Wed, 2016-02-03 at 09:40 +0800, Cawa Cheng (鄭曄禧) wrote:
> 
> -Original Message-
> From: djku...@google.com [mailto:djku...@google.com] On Behalf Of Daniel Kurtz
> Sent: Wednesday, February 03, 2016 12:22 AM
> To: Hs Liao (廖宏祥)
> Cc: Rob Herring; Matthias Brugger; Sascha Hauer; open list:OPEN FIRMWARE 
> AND...; linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; 
> moderated list:ARM/Mediatek SoC support; srv_heupstream; Sascha Hauer; 
> Philipp Zabel; Nicolas Boichat; CK Hu (胡俊光); Cawa Cheng (鄭曄禧); Bibby Hsieh 
> (謝濟遠); YT Shen (沈岳霆); Daoyuan Huang (黃道原); Damon Chu (朱峻賢); Josh-YC Liu 
> (劉育誠); Glory Hung (洪智瑋); Yong Wu (吴勇)
> Subject: Re: [RFC 3/3] CMDQ: Mediatek CMDQ driver
> 
> On Tue, Feb 2, 2016 at 2:48 PM, Horng-Shyang Liao  
> wrote:
> > On Mon, 2016-02-01 at 18:22 +0800, Daniel Kurtz wrote:
> >> On Mon, Feb 1, 2016 at 2:20 PM, Horng-Shyang Liao  
> >> wrote:
> >> > On Mon, 2016-02-01 at 12:15 +0800, Daniel Kurtz wrote:
> >> >> On Mon, Feb 1, 2016 at 10:04 AM, Horng-Shyang Liao 
> >> >>  wrote:
> >> >> >
> >> >> > On Fri, 2016-01-29 at 21:15 +0800, Daniel Kurtz wrote:
> >> >> > > On Fri, Jan 29, 2016 at 8:24 PM, Horng-Shyang Liao 
> >> >> > >  wrote:
> >> >> > > > On Fri, 2016-01-29 at 16:42 +0800, Daniel Kurtz wrote:
> >> >> > > >> On Fri, Jan 29, 2016 at 3:39 PM, Horng-Shyang Liao 
> >> >> > > >>  wrote:
> >> >> > > >> > Hi Dan,
> >> >> > > >> >
> >> >> > > >> > Many thanks for your comments and time.
> >> >> > > >> > I reply my plan inline.
> >> >> > > >> >
> >> >> > > >> >
> >> >> > > >> > On Thu, 2016-01-28 at 12:49 +0800, Daniel Kurtz wrote:
> >> >> > > >> >> Hi HS,
> >> >> > > >> >>
> >> >> > > >> >> Sorry for the delay.  It is hard to find time to review 
> >> >> > > >> >> a >3700 line driver :-o in detail
> >> >> > > >> >>
> >> >> > > >> >> Some review comments inline, although I still do not 
> >> >> > > >> >> completely understand how all that this driver does and how 
> >> >> > > >> >> it works.
> >> >> > > >> >> I'll try to find time to go through this driver in 
> >> >> > > >> >> detail again next time you post it for review.
> >> >> > > >> >>
> >> >> > > >> >> On Tue, Jan 19, 2016 at 9:14 PM,   
> >> >> > > >> >> wrote:
> >> >> > > >> >> > From: HS Liao 
> >> >> > > >> >> >
> >> >> > > >> >> > This patch is first version of Mediatek Command 
> >> >> > > >> >> > Queue(CMDQ) driver. The CMDQ is used to help 
> >> >> > > >> >> > read/write registers with critical time limitation, 
> >> >> > > >> >> > such as updating display configuration during the vblank. 
> >> >> > > >> >> > It controls Global Command Engine (GCE) hardware to achieve 
> >> >> > > >> >> > this requirement.
> >> >> > > >> >> > Currently, CMDQ only supports display related 
> >> >> > > >> >> > hardwares, but we expect it can be extended to other 
> >> >> > > >> >> > hardwares for future requirements.
> >> >> > > >> >> >
> >> >> > > >> >> > Signed-off-by: HS Liao 
> >> >> > > >> >>
> >> >> > > >> >> [snip]
> >> >> > > >> >>
> >> >> > > >> >> > diff --git a/drivers/soc/mediatek/mtk-cmdq.c 
> >> >> > > >> >> > b/drivers/soc/mediatek/mtk-cmdq.c new file mode 100644 
> >> >> > > >> >> > index 000..7570f00
> >> >> > > >> >> > --- /dev/null
> >> >> > > >> >> > +++ b/drivers/soc/mediatek/mtk-cmdq.c
> >> >> > > >
> >> >> > > > [snip]
> >> >> > > >
> >> >> > > >> >> > +static const struct cmdq_subsys g_subsys[] = {
> >> >> > > >> >> > +   {0x1400, 1, "MMSYS"},
> >> >> > > >> >> > +   {0x1401, 2, "DISP"},
> >> >> > > >> >> > +   {0x1402, 3, "DISP"},
> >> >> > > >> >>
> >> >> > > >> >> This isn't going to scale.  These addresses could be 
> >> >> > > >> >> different on different chips.
> >> >> > > >> >> Instead of a static table like this, we probably need 
> >> >> > > >> >> specify to the connection between gce and other devices 
> >> >> > > >> >> via devicetree phandles, and then use the phandles to 
> >> >> > > >> >> lookup the corresponding device address range.
> >> >> > > >> >
> >> >> > > >> > I will define them in device tree.
> >> >> > > >> > E.g.
> >> >> > > >> > cmdq {
> >> >> > > >> >   reg_domain = 0x1400, 0x1401, 0x1402 }
> >> >> > > >>
> >> >> > > >> The devicetree should only model hardware relationships, 
> >> >> > > >> not software considerations.
> >> >> > > >>
> >> >> > > >> Is the hardware constraint here for using gce with various 
> >> >> > > >> other hardware blocks?  I think we already model this by 
> >> >> > > >> only providing a gce phandle in the device tree nodes for 
> >> >> > > >> those devices that can use gce.
> >> >> > > >>
> >> >> > > >> Looking at the driver closer, as far as I can tell, the 
> >> >> > > >> whole subsys concept is a purely software abstraction, and 
> >> >> > > >> only used to debug the CMDQ_CODE_WRITE command.  In fact, 
> >> >> > > >> AFAICT, 

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

[Daniel Kurtz]

> 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 = <>;

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