Re: [PATCH 01/12] drm/amdgpu: add amd_gnb_bus support

From: Alex Deucher <alexdeucher@gmail.com>
To: Mark Brown <broonie@kernel.org>, Felix Kuehling <Felix.Kuehling@amd.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	maruthi.bayyavarapu@amd.com, lgirdwood@gmail.com,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	perex@perex.cz, Alex Deucher <alexander.deucher@amd.com>
Subject: Re: [PATCH 01/12] drm/amdgpu: add amd_gnb_bus support
Date: Fri, 7 Aug 2015 10:17:36 -0400	[thread overview]
Message-ID: <CADnq5_NihZCFEaL150Kt0LWCUBp6eQzne-O0JcCFE0-vHj7ZBQ@mail.gmail.com> (raw)
In-Reply-To: <20150807102508.GL20873@sirena.org.uk>

On Fri, Aug 7, 2015 at 6:25 AM, Mark Brown <broonie@kernel.org> wrote:
> On Thu, Aug 06, 2015 at 10:25:02AM -0400, Alex Deucher wrote:
>> From: Chunming Zhou <david1.zhou@amd.com>
>>
>> This is used by the incoming ACP driver.  The DMA
>> engine for the i2s audio codec is part of the GPU.
>>
>> This exposes an amd gnb bus for the i2s codec to
>> hang off of.
>
> Could you be more specific about what an "amd gnd bus" is please?

It's bus to hang hw blocks of the GPU on that are controlled by other
subsystems.

>
>> +enum amd_gnb_bus_ip {
>> +     AMD_GNB_IP_ACP_DMA,
>> +     AMD_GNB_IP_ACP_I2S,
>> +     AMD_GNB_IP_ACP_PCM,
>> +     AMD_GNB_IP_ISP,
>> +     AMD_GNB_IP_NUM
>> +};
>> +
>> +struct amd_gnb_bus_dev {
>> +     struct device dev; /* generic device interface */
>> +     enum amd_gnb_bus_ip ip;
>> +     /* private data can be acp_handle/isp_handle etc.*/
>> +     void *private_data;
>> +};
>
> Looking at the code I'm not seeing too much bus specific except for the
> above which looks like the sort of device we usually represent as a MFD
> (with the MFD providing resource distribution and arbitration between
> various component devices which fit into the subsystem).  Why code a new
> bus for this device?

Adding Felix who did worked on the design for this.  The idea is that
there are hw blocks on the GPU that are controlled by drivers that are
part of other subsystems.  Those drivers need access to resources
(e.g., the MMIO aperture) controlled by the GPU driver.  I guess this
is a MFD of sorts.  If this is not the preferred way to handle this
type of device, what is?  Can you point me to another driver that
handles this differently?

Alex
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel