As we look at upstreaming more support for the Qualcomm MSM SoCs there are a number of drivers or library like routines that are unique to the MSM platform, we are thinking that putting them under:
drivers/platform/qcom/
would make sense. In addition there are headers that might need to get shared with drivers in other locations so I wanted to see what the take was on introducing:
include/linux/platform/qcom/
An example driver would be the means we utilize to communicate memory regions between various HW blocks on the SoC. So a video/media core driver might need access to a header/functions from the memory region driver.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Thu, Oct 03, 2013 at 09:45:38AM -0500, Kumar Gala wrote:
> As we look at upstreaming more support for the Qualcomm MSM SoCs there
> are a number of drivers or library like routines that are unique to
> the MSM platform, we are thinking that putting them under:
>
> drivers/platform/qcom/
What type of drivers are these? Shouldn't they really go under the
specific driver type directory instead?
> would make sense. In addition there are headers that might need to
> get shared with drivers in other locations so I wanted to see what the
> take was on introducing:
>
> include/linux/platform/qcom/
>
> An example driver would be the means we utilize to communicate memory
> regions between various HW blocks on the SoC. So a video/media core
> driver might need access to a header/functions from the memory region
> driver.
Isn't there arch-specific include directories already that are good for
stuff like this?
thanks,
greg k-h
On Oct 3, 2013, at 10:27 AM, Greg Kroah-Hartman wrote:
> On Thu, Oct 03, 2013 at 09:45:38AM -0500, Kumar Gala wrote:
>> As we look at upstreaming more support for the Qualcomm MSM SoCs there
>> are a number of drivers or library like routines that are unique to
>> the MSM platform, we are thinking that putting them under:
>>
>> drivers/platform/qcom/
>
> What type of drivers are these? Shouldn't they really go under the
> specific driver type directory instead?
If there isn't an existing driver/ dir for this I dont see how it can go there, I'm not also not really a fan of trying to artificial put something that is highly SoC specific into something generic of this nature.
>> would make sense. In addition there are headers that might need to
>> get shared with drivers in other locations so I wanted to see what the
>> take was on introducing:
>>
>> include/linux/platform/qcom/
>>
>> An example driver would be the means we utilize to communicate memory
>> regions between various HW blocks on the SoC. So a video/media core
>> driver might need access to a header/functions from the memory region
>> driver.
>
> Isn't there arch-specific include directories already that are good for
> stuff like this?
Well, we expect at some point in needing to share with arm64 as well so that causes issues (one of the reason I'm not a fan of the split between the two arch's).
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Thu, Oct 03, 2013 at 11:21:10AM -0500, Kumar Gala wrote:
>
> On Oct 3, 2013, at 10:27 AM, Greg Kroah-Hartman wrote:
>
> > On Thu, Oct 03, 2013 at 09:45:38AM -0500, Kumar Gala wrote:
> >> As we look at upstreaming more support for the Qualcomm MSM SoCs there
> >> are a number of drivers or library like routines that are unique to
> >> the MSM platform, we are thinking that putting them under:
> >>
> >> drivers/platform/qcom/
> >
> > What type of drivers are these? Shouldn't they really go under the
> > specific driver type directory instead?
>
> If there isn't an existing driver/ dir for this I dont see how it can go there, I'm not also not really a fan of trying to artificial put something that is highly SoC specific into something generic of this nature.
Loose a line-wrap somewhere?...
Anyway, you didn't answer my question, so why do I need to answer yours?
snarkily,
greg k-h
On Oct 3, 2013, at 11:25 AM, Greg Kroah-Hartman wrote:
> On Thu, Oct 03, 2013 at 11:21:10AM -0500, Kumar Gala wrote:
>>
>> On Oct 3, 2013, at 10:27 AM, Greg Kroah-Hartman wrote:
>>
>>> On Thu, Oct 03, 2013 at 09:45:38AM -0500, Kumar Gala wrote:
>>>> As we look at upstreaming more support for the Qualcomm MSM SoCs there
>>>> are a number of drivers or library like routines that are unique to
>>>> the MSM platform, we are thinking that putting them under:
>>>>
>>>> drivers/platform/qcom/
>>>
>>> What type of drivers are these? Shouldn't they really go under the
>>> specific driver type directory instead?
>>
>> If there isn't an existing driver/ dir for this I dont see how it can go there, I'm not also not really a fan of trying to artificial put something that is highly SoC specific into something generic of this nature.
>
> Loose a line-wrap somewhere?...
>
> Anyway, you didn't answer my question, so why do I need to answer yours?
Sorry about that. I gave one example in the initial email about a driver that is used to get regions of memory used by processors or HW blocks on the SoC.
I'm still sorting through the mass of code to figure out what all is there and where might be the best place for it. However, I do think we will end up with some SoC specific bits that highly unique to qualcomm SoCs that just dont fit anywhere else and thus drivers/platforms seemed the best location.
As we submit things upstream I'm more than happy to move stuff around based on feedback.
One example you can look at is arch/arm/mach-msm/smd.c, this is a mix of the memory region support (which we've since split out) and some multiproc messaging functionality.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
On Thu, Oct 3, 2013 at 7:45 AM, Kumar Gala <[email protected]> wrote:
> As we look at upstreaming more support for the Qualcomm MSM SoCs there are a number of drivers or library like routines that are unique to the MSM platform, we are thinking that putting them under:
>
> drivers/platform/qcom/
drivers/platform has traditionally been used for OEM/product platform
drivers, i.e. stuff such as laptop drivers or server management module
drivers, i.e. not platforms in "SoC family" sense.
I don't have a good answer though. If it wasn't for the arm64 fork,
locating these under arch/arm somewhere would really be the reasonable
answer, like we used to do on powerpc. :(
-Olof
On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
> I don't have a good answer though. If it wasn't for the arm64 fork,
> locating these under arch/arm somewhere would really be the reasonable
> answer, like we used to do on powerpc. :(
Sounds like yet-another-good reason why there shouldn't be an arm64
"fork" at all :(
The arm community created this mess, you all can fix it up, it's not too
late.
greg k-h
On Thu, Oct 3, 2013 at 10:09 AM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
>> I don't have a good answer though. If it wasn't for the arm64 fork,
>> locating these under arch/arm somewhere would really be the reasonable
>> answer, like we used to do on powerpc. :(
>
> Sounds like yet-another-good reason why there shouldn't be an arm64
> "fork" at all :(
Doing a fork gives a chance at a clean slate refresh of platform
support, which is in itself quite useful. But indeed it causes some
things to be more complicated.
It's a common complaint that "everybody who ever forked for 64-bit
have later merged", and that's true, but that doesn't mean there's no
value in forking (and perhaps later merging), instead of adding on top
to start with.
> The arm community created this mess, you all can fix it up, it's not too
> late.
It wouldn't be a huge deal to add something like arch/arm/syslib and
give some of the system library-type code a home there -- stuff like
resource allocation libraries, etc. I don't think we want to collect
all the back-end drivers in there though, just libraries.
I think many of us are hesitant to introduce something that runs the
risk of becoming a dumping ground for all these "I don't know where to
put them, so here you go" drivers, since we've spent so much time
cleaning them all up and de-forking per-vendor implementations of
similar things.
Still, there's little point in trying to artificially remove drivers
that are 100% vendor unique from a vendor-specific location just for
the sake of it. And we do have a single merge path today through
arm-soc to catch a lot of these things as they get introduced --
almost more so than if everyone adds their own driver/ directory and
declare themselves maintainer of that subtree.
Kumar, it would be useful to get a bit of an inventory of what you
know you need a home for. I know the APM guys have a queue manager
(arm64-only) that handles things such as resource allocation for
ethernet, etc, that they need a home for. It's not a pure library
though, since there's also error interrupts, etc, to deal with.
-Olof
On Thu, Oct 03, 2013 at 06:54:07PM +0100, Olof Johansson wrote:
> On Thu, Oct 3, 2013 at 10:09 AM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
> >> I don't have a good answer though. If it wasn't for the arm64 fork,
> >> locating these under arch/arm somewhere would really be the reasonable
> >> answer, like we used to do on powerpc. :(
> >
> > Sounds like yet-another-good reason why there shouldn't be an arm64
> > "fork" at all :(
>
> Doing a fork gives a chance at a clean slate refresh of platform
> support, which is in itself quite useful. But indeed it causes some
> things to be more complicated.
Also note that arm64 work started (internally) before the arm-soc was
formed and it was nearing upstreaming at a time when the arm-soc was
still undergoing heavy clean-up.
Of course, there is always a balance between advantages and
disadvantages but the main benefits are a clean implementation of
AArch64 architecture support (without legacy baggage) and forcing SoC
people to clean up the code for AArch64 (e.g. default single Image,
decoupling booting protocols from SoC initialisation, firmware interface
standardisation, resisting the urge to add SoC code under arch/arm64/).
> It's a common complaint that "everybody who ever forked for 64-bit
> have later merged", and that's true, but that doesn't mean there's no
> value in forking (and perhaps later merging), instead of adding on top
> to start with.
Exactly. Later merging is possible, but such process, to produce
clean/maintainable/shareable code, needs additional clean-up in the
32-bit ARM architecture code (at least breaking recent ARMv7 support
from legacy architectures). Otherwise we end up with either a less than
clean arm64 re-port on top of arm or just completely separate files
artificially forced under the same arch directory.
Where code sharing makes sense (e.g. ARM KVM and Xen), the arm64
Makefiles already reference arch/arm/. It's not ideal but it's a
trade-off for the time being.
> > The arm community created this mess, you all can fix it up, it's not too
> > late.
>
> It wouldn't be a huge deal to add something like arch/arm/syslib and
> give some of the system library-type code a home there -- stuff like
> resource allocation libraries, etc. I don't think we want to collect
> all the back-end drivers in there though, just libraries.
On the SoC part, we need to analyse what exactly needs sharing, whether
it's a library used by multiple drivers (and arguably the library could
also go under drivers/) or whether it's some SoC initialisation that
could be better done before Linux is started.
--
Catalin
On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
> I don't have a good answer though. If it wasn't for the arm64 fork,
> locating these under arch/arm somewhere would really be the reasonable
> answer, like we used to do on powerpc. :(
Are you seriously suggesting going back to having drivers under arch/arm
because we can't find a home for them in the drivers subtree?
Having made a big thing about things as small as clock source drivers,
IRQ drivers and such like which "shouldn't be under arch/arm" and moving
them out, to then say about finding somewhere under arch/arm for drivers
is very much a case of double-standards.
I've heard this accusation that we have too many drivers in arch/arm
many times, and although we've made some progress getting things like
clock and IRQ drivers out of arch/arm, we're still a long way from
sorting that out. Or maybe that original accusation was baseless for
modern kernels, based on the old 1.x days when we had a arch/arm/drivers
subdirectory which people have a hard time forgetting?
So, no, there will be no new drivers under arch/arm. They must be in the
drivers subtree somewhere.
On Thu, Oct 03, 2013 at 10:09:14AM -0700, Greg Kroah-Hartman wrote:
> On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
> > I don't have a good answer though. If it wasn't for the arm64 fork,
> > locating these under arch/arm somewhere would really be the reasonable
> > answer, like we used to do on powerpc. :(
>
> Sounds like yet-another-good reason why there shouldn't be an arm64
> "fork" at all :(
>
> The arm community created this mess, you all can fix it up, it's not too
> late.
I said at the time, way before arm64 was merged that it should not be a
separate arch. Every bit of feedback I gave on arm64 got shouted down
by Catalin. ARM64 is Catalin's baby and he wants to protect it at all
costs. I'm surprised Linus even pulled it in with no argument.
On Thu, Oct 03, 2013 at 10:54:07AM -0700, Olof Johansson wrote:
> It wouldn't be a huge deal to add something like arch/arm/syslib and
> give some of the system library-type code a home there -- stuff like
> resource allocation libraries, etc. I don't think we want to collect
> all the back-end drivers in there though, just libraries.
We don't need yet another subdirectory in arch/arm - yes, that's a
favourite way of avoiding any issues, but really it's not the right
answer. We already have a place for shared cross-platform code, and
it's called arch/arm/common.
> I think many of us are hesitant to introduce something that runs the
> risk of becoming a dumping ground for all these "I don't know where to
> put them, so here you go" drivers, since we've spent so much time
> cleaning them all up and de-forking per-vendor implementations of
> similar things.
"Drivers go under drivers/" is what we've decided. If we want to change
that, then we should move all those IRQ, gpio and clock drivers back out
of the drivers/ subtree, because many of them are SoC specific.
Please, think back to why we made the original decision(s) to move this
stuff out of arch/arm.
On Fri, Oct 04, 2013 at 12:43:40PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 03, 2013 at 10:09:14AM -0700, Greg Kroah-Hartman wrote:
> > On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
> > > I don't have a good answer though. If it wasn't for the arm64 fork,
> > > locating these under arch/arm somewhere would really be the reasonable
> > > answer, like we used to do on powerpc. :(
> >
> > Sounds like yet-another-good reason why there shouldn't be an arm64
> > "fork" at all :(
> >
> > The arm community created this mess, you all can fix it up, it's not too
> > late.
>
> I said at the time, way before arm64 was merged that it should not be a
> separate arch. Every bit of feedback I gave on arm64 got shouted down
> by Catalin. ARM64 is Catalin's baby and he wants to protect it at all
> costs.
My counter arguments weren't probably clear to you. I want to protect a
clean, legacy-free AArch64 implementation at all costs.
--
Catalin
On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote:
>
> So, no, there will be no new drivers under arch/arm. They must be in the
> drivers subtree somewhere.
I have no objection with this, and encourage it.
greg k-h
On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote:
>>
>> So, no, there will be no new drivers under arch/arm. They must be in the
>> drivers subtree somewhere.
>
> I have no objection with this, and encourage it.
Ok, so these are some of the requirements as far as I see it:
* No per-vendor driver dumping ground under drivers/* (i.e. no
drivers/platform/<soc vendor>/)
* No weirdly constructed single-driver directories directly under
drivers/* (we already have a few and should look at moving those)
because nothing else fits
* We need some sort of convention on dependencies. Several of these
are more libraries than drivers, i.e. we'll have cross-calls for
things like queue management, resource allocation, etc. So having a
single location to hold most of these makes sense instead of
everything cross-depending on everything else.
Based on the above, how about we create something like
drivers/resourcemgr to hold these? I think at least parts of the
mvebu-mbus driver that ended up under drivers/bus might be a fit to
move there. The APM queue allocator would likely be a fit, and maybe
some of the qualcomm stuff. Kumar, what are your thoughts on that?
Greg?
-Olof
On Friday 04 October 2013 12:48 PM, Olof Johansson wrote:
> On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman
> <[email protected]> wrote:
>> On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote:
>>>
>>> So, no, there will be no new drivers under arch/arm. They must be in the
>>> drivers subtree somewhere.
>>
>> I have no objection with this, and encourage it.
>
> Ok, so these are some of the requirements as far as I see it:
>
> * No per-vendor driver dumping ground under drivers/* (i.e. no
> drivers/platform/<soc vendor>/)
> * No weirdly constructed single-driver directories directly under
> drivers/* (we already have a few and should look at moving those)
> because nothing else fits
> * We need some sort of convention on dependencies. Several of these
> are more libraries than drivers, i.e. we'll have cross-calls for
> things like queue management, resource allocation, etc. So having a
> single location to hold most of these makes sense instead of
> everything cross-depending on everything else.
>
> Based on the above, how about we create something like
> drivers/resourcemgr to hold these? I think at least parts of the
> mvebu-mbus driver that ended up under drivers/bus might be a fit to
> move there. The APM queue allocator would likely be a fit, and maybe
> some of the qualcomm stuff. Kumar, what are your thoughts on that?
Slightly different question but relevant to th thread w.r.t the Queue
allocator/manager. We are also interested for TI Keystone SOCs.
Currently we have generic drivers/hwqueue/ with core hwqueue
layer implementing the standard hardware queue descriptor push/pop
and notification mechanisms and then Keystone specific
driver using those core functionalities. I read most of the
networking SOCs has some sort of hwqueues but not sure about
the its implementations. So just thought of bringing
it into the thread discussion to see if hwqueue core layer is
of any interest to other SOCs.
Regards,
Santosh
On Fri, Oct 04, 2013 at 09:48:41AM -0700, Olof Johansson wrote:
> On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman
> <[email protected]> wrote:
> > On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote:
> >>
> >> So, no, there will be no new drivers under arch/arm. They must be in the
> >> drivers subtree somewhere.
> >
> > I have no objection with this, and encourage it.
>
> Ok, so these are some of the requirements as far as I see it:
>
> * No per-vendor driver dumping ground under drivers/* (i.e. no
> drivers/platform/<soc vendor>/)
Yes.
> * No weirdly constructed single-driver directories directly under
> drivers/* (we already have a few and should look at moving those)
> because nothing else fits
Yes, we should see about moving some of the ones we currently have,
drivers/ntb/ is one example that I couldn't think of a better place to
put it. I guess drivers/misc/ really would be best for a bunch of
these. As an example, drivers/misc/mic/ is way larger than
drivers/ntb/.
> * We need some sort of convention on dependencies. Several of these
> are more libraries than drivers, i.e. we'll have cross-calls for
> things like queue management, resource allocation, etc. So having a
> single location to hold most of these makes sense instead of
> everything cross-depending on everything else.
What's wrong with lib/ for that? Isn't that supposed to be where this
type of thing goes?
> Based on the above, how about we create something like
> drivers/resourcemgr to hold these? I think at least parts of the
> mvebu-mbus driver that ended up under drivers/bus might be a fit to
> move there. The APM queue allocator would likely be a fit, and maybe
> some of the qualcomm stuff. Kumar, what are your thoughts on that?
> Greg?
lib/ does look "big", but we also have kernel/ for the current resource
stuff, as it is core code. Why not use that?
thanks,
greg k-h
Hi,
> As we look at upstreaming more support for the Qualcomm MSM SoCs there are a number of drivers or library like routines that are unique to the MSM platform, we are thinking that putting them under:
just a question, is this code the one you have already in
codeaurora for 8974/8226/8626/8610 etc?
Thanks,
Andi
On 10/5/2013 10:13 AM, Greg Kroah-Hartman wrote:
> On Fri, Oct 04, 2013 at 09:48:41AM -0700, Olof Johansson wrote:
>> On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman
>> <[email protected]> wrote:
>>> On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote:
>>>> So, no, there will be no new drivers under arch/arm. They must be in the
>>>> drivers subtree somewhere.
>>> I have no objection with this, and encourage it.
>> Ok, so these are some of the requirements as far as I see it:
>>
>> * No per-vendor driver dumping ground under drivers/* (i.e. no
>> drivers/platform/<soc vendor>/)
> Yes.
We agree that there is no need for a dump *all* drivers under
arm/mach-foo in drivers/platform/foo/. The msm bus driver would be added
under drivers/bus/. But, we still have some drivers which are quite SoC
specific and not in the general category of the sub-directories present
under drivers.
As Kumar mentioned earlier -
An example driver would be the means we utilize to communicate memory regions between various HW blocks on the SoC. So a video/media core driver might need access to a header/functions from the memory region driver.
Would drivers/misc/qcom-* or drivers/misc/qcom/* be a reasonable place to add them ? and the headers could go into include/linux/qcom-*.h
<snip>
Thanks,
Rohit Vaswani
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
On Mon, Oct 07, 2013 at 05:26:57PM -0700, Rohit Vaswani wrote:
> On 10/5/2013 10:13 AM, Greg Kroah-Hartman wrote:
> > On Fri, Oct 04, 2013 at 09:48:41AM -0700, Olof Johansson wrote:
> >> On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman
> >> <[email protected]> wrote:
> >>> On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote:
> >>>> So, no, there will be no new drivers under arch/arm. They must be in the
> >>>> drivers subtree somewhere.
> >>> I have no objection with this, and encourage it.
> >> Ok, so these are some of the requirements as far as I see it:
> >>
> >> * No per-vendor driver dumping ground under drivers/* (i.e. no
> >> drivers/platform/<soc vendor>/)
> > Yes.
>
> We agree that there is no need for a dump *all* drivers under
> arm/mach-foo in drivers/platform/foo/. The msm bus driver would be added
> under drivers/bus/. But, we still have some drivers which are quite SoC
> specific and not in the general category of the sub-directories present
> under drivers.
> As Kumar mentioned earlier -
>
> An example driver would be the means we utilize to communicate memory
> regions between various HW blocks on the SoC. So a video/media core
> driver might need access to a header/functions from the memory region
> driver.
>
> Would drivers/misc/qcom-* or drivers/misc/qcom/* be a reasonable place
> to add them ? and the headers could go into include/linux/qcom-*.h
That seems reasonable, but I'd have to see the code to verify this.
greg k-h
On 10/6/2013 11:48 PM, Andi Shyti wrote:
> Hi,
>
>> As we look at upstreaming more support for the Qualcomm MSM SoCs there are a number of drivers or library like routines that are unique to the MSM platform, we are thinking that putting them under:
> just a question, is this code the one you have already in
> codeaurora for 8974/8226/8626/8610 etc?
Yes.
> Thanks,
> Andi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks,
Rohit Vaswani
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
> >just a question, is this code the one you have already in
> >codeaurora for 8974/8226/8626/8610 etc?
> Yes.
Finally, I would say! But you should have done this much earlier
so that you could have made the life of your customers easier and
maybe they could have helped you on upstreaming the code.
Now you have to dump tons of patches, it will take ages.
Andi