Messages in this thread | | | Subject | Re: [GIT_PULL] SOC: TI Keystone Ring Accelerator driver for v5.6 | From | santosh.shilimkar@oracle ... | Date | Fri, 17 Jan 2020 10:20:35 -0800 |
| |
On 1/17/20 10:11 AM, Olof Johansson wrote: > On Thu, Jan 16, 2020 at 9:05 PM <santosh.shilimkar@oracle.com> wrote: >> >> On 1/16/20 4:03 PM, Olof Johansson wrote: >>> Hi, >>> >>> On Thu, Jan 16, 2020 at 12:07:39PM -0800, Santosh Shilimkar wrote: >>>> Its bit late for pull request, but if possible, please pull it to >>>> soc drivers tree. >>>> >>>> The following changes since commit e42617b825f8073569da76dc4510bfa019b1c35a: >>>> >>>> Linux 5.5-rc1 (2019-12-08 14:57:55 -0800) >>>> >>>> are available in the git repository at: >>>> >>>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/drivers_soc_for_5.6 >>>> >>>> for you to fetch changes up to 3277e8aa2504d97e022ecb9777d784ac1a439d36: >>>> >>>> soc: ti: k3: add navss ringacc driver (2020-01-15 10:07:27 -0800) >>>> >>>> ---------------------------------------------------------------- >>>> SOC: TI Keystone Ring Accelerator driver >>>> >>>> The Ring Accelerator (RINGACC or RA) provides hardware acceleration to >>>> enable straightforward passing of work between a producer and a consumer. >>>> There is one RINGACC module per NAVSS on TI AM65x SoCs. >>> >>> This driver doesn't seem to have exported symbols, and no in-kernel >>> users. So how will it be used? >>> >>> Usually we ask to hold off until the consuming side/drivers are also ready. >>> >> The other patches getting merged via Vinod's tree. The combined series >> is split into couple of series. Vinod is going to pull this branch >> and apply rest of the patchset. And then couple of additional consumer >> drivers will get posted. > > Ok -- might have been useful to get that in the tag description for > context. Something to consider next time. > Sure. Will keep that in mind.
>>> Also, is there a reason this is under drivers/soc/ instead of somewhere more >>> suitable in the drivers subsystem? It's not "soc glue code" in the same way as >>> drivers/soc was intended originally. >>> >> These kind of SOC IP drivers, we put into drivers/soc/ because of lack >> of specific subsystem where they fit in. Navigator was also similar example. > > Hmm. At some point we'll have to push the brakes on this, since > drivers/soc can't become a catch-all for random stuff like the old > mach directories were. But it's tricky to tell just when -- sometimes > you have to let the mess show up too. > > I'll merge this when I do the next pass (today, likely). > Thanks Olof !!
| |