From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: Getting your opinion about the best place to put one specific device driver...
Date: Tue, 12 Feb 2013 08:57:13 -0800 [thread overview]
Message-ID: <20130212165713.GG4801@atomide.com> (raw)
In-Reply-To: <511A6D1E.50705@stericsson.com>
Hi,
* Jean-Nicolas GRAUX <jean-nicolas.graux@stericsson.com> [130212 08:33]:
> Arnd, here are my answers below.
>
> Le 02/12/2013 03:54 PM, Arnd Bergmann a ?crit :
> >On Tuesday 12 February 2013, Jean-Nicolas GRAUX wrote:
> >>ello, Arnd, Olof. First, let me introduce myself quickly.
> >>I am working in Stericsson and i am a colleague of Linus Walleij.
> >>We are currently doing some cleaning in our mach-ux500 ARM machine.
> >>
> >>Among other things, the U8500 SoC and its derivatives embed one small IP
> >>called the "hardware observer".
> >>This is used for hardware debug purpose and it provides the ability to
> >>output some
> >>modem, power, clocking, ..., hardware signals on 18 external wires.
> >>
> >>We did one small platform device driver to handle this piece of hardware.
> >>In the patch attached to this file, we kept the code in the mach-ux500
> >>machine folder.
> >>But we are wondering where is the best place to put that stuff.
> >>So, the question is: where should we put this code in the kernel tree ?
> >Hi Jean-Nicolas,
> >
> >I think I need some more information to understand what that interface
> >you are driving is actually about, since that is not clear from your
> >description or from reading the source code.
> >
> >Why are there exactly 18 wires?
> As you can imagine, this module is very specific to the ux500
> digital baseband family.
> So, ux500 SoCs simply provide 18 external IOs that may be used to
> observe some critical hardware signals.
> Depending on what has been configured in the hwobs control
> registers, we are able to observe
> signals from the modem, the ddr controllers, the prcmu, the gfx ip,
> the clock tree, ...
Sounds very similar to what we have on omaps as hwobs. AFAIK that
module is just multiplexing signals. So maybe take a look how it
would fit into drivers/pinctrl?
At least the omap hwobs could in theory already be handled by
pinctrl-single.c.
Regards,
Tony
next prev parent reply other threads:[~2013-02-12 16:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 9:44 Getting your opinion about the best place to put one specific device driver Jean-Nicolas GRAUX
2013-02-12 14:54 ` Arnd Bergmann
2013-02-12 16:26 ` Jean-Nicolas GRAUX
2013-02-12 16:57 ` Tony Lindgren [this message]
2013-02-12 17:41 ` Arnd Bergmann
2013-02-13 9:16 ` Jean-Nicolas GRAUX
2013-02-13 11:04 ` Arnd Bergmann
2013-02-13 16:54 ` Tony Lindgren
2013-02-14 10:28 ` Peter De Schrijver
2013-02-14 8:52 ` Linus Walleij
2013-02-14 16:59 ` Tony Lindgren
2013-02-13 9:45 ` Peter De Schrijver
2013-02-13 9:47 ` Jean-Nicolas GRAUX
2013-02-13 16:52 ` Tony Lindgren
2013-02-12 15:09 ` Russell King - ARM Linux
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=20130212165713.GG4801@atomide.com \
--to=tony@atomide.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).