Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1307386 > unrolled thread
| Started by | Tomeu Vizoso <tomeu@tomeuvizoso.net> |
|---|---|
| First post | 2016-01-12 14:10 +0100 |
| Last post | 2016-01-13 20:10 +0100 |
| Articles | 10 on this page of 50 — 13 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH 0/4] UART slave device support - version 4 Tomeu Vizoso <tomeu@tomeuvizoso.net> - 2016-01-12 14:10 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-12 14:30 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Mark Rutland <mark.rutland@arm.com> - 2016-01-13 20:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Mark Rutland <mark.rutland@arm.com> - 2016-01-15 12:10 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 16:10 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Andrey Vostrikov <andrey.vostrikov@cogentembedded.com> - 2016-01-15 16:50 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 17:10 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Peter Hurley <peter@hurleysoftware.com> - 2016-01-15 18:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 18:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Peter Hurley <peter@hurleysoftware.com> - 2016-01-15 18:50 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 19:00 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Peter Hurley <peter@hurleysoftware.com> - 2016-01-15 20:30 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 22:30 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Rob Herring <robherring2@gmail.com> - 2016-01-15 23:50 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Vostrikov Andrey <andrey.vostrikov@cogentembedded.com> - 2016-01-16 08:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Rob Herring <robh@kernel.org> - 2016-01-17 00:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-17 10:00 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-17 15:30 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-17 19:00 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-17 20:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-18 09:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Andrey Vostrikov <andrey.vostrikov@cogentembedded.com> - 2016-01-18 10:00 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-18 13:00 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-18 12:30 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-18 22:00 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-18 23:10 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-18 23:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-19 15:30 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-20 18:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-20 17:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-20 18:50 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-20 19:10 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Tomeu Vizoso <tomeu@tomeuvizoso.net> - 2016-01-22 17:00 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Rob Herring <robherring2@gmail.com> - 2016-01-22 18:00 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-22 21:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Andreas Kemnade <andreas@kemnade.info> - 2016-01-23 08:50 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-23 13:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-23 18:30 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-23 23:10 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2016-01-24 18:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-25 11:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Andreas Kemnade <andreas@kemnade.info> - 2016-01-19 07:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-01-20 20:40 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Vostrikov Andrey <andrey.vostrikov@cogentembedded.com> - 2016-01-20 21:10 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Mark Rutland <mark.rutland@arm.com> - 2016-01-15 17:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 20:20 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 Pavel Machek <pavel@ucw.cz> - 2016-01-15 20:50 +0100
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 21:40 +0100
Re: [PATCH 0/4] UART slave device support - version 4 NeilBrown <neil@brown.name> - 2016-01-12 22:30 +0100
Re: [PATCH 0/4] UART slave device support - version 4 Pavel Machek <pavel@ucw.cz> - 2016-01-13 20:10 +0100
Page 3 of 3 — ← Prev page 1 2 [3]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-01-25 11:40 +0100 |
| Subject | Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 |
| Message-ID | <qUMIV-2z3-13@gated-at.bofh.it> |
| In reply to | #1315937 |
Hi Alan, Am 24.01.2016 um 18:10 schrieb One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>: >>> but by having only the >>> minimum necessary in the kernel. Unix >> >> I think you are confusing it with the goals of microkernels (e.g. Mach or Hurd). > > No and the quote below is from Doug McIlroy - who amongst other thing > invented pipes. Which is a brilliant concept. > >>> >>> "We used to sit around in the Unix Room saying, 'What can we throw out? >>> Why is there this option?" - Doug McIlroy Maybe I am interpreting differently, but "throwing out unnecessary things from Unix" is logically not the same as "having the minimum necessary in the kernel". The latter appears to be implying to do *everything* which can be done in user space. This is what I mean that the goal of throwing out everything not necessary from the kernel leads to micro-kernel concepts. And neither Unix nor Linux did throw out enough to become a microkernel. So they still have components which could be thrown out and moved to user space. And Unix is kernel + user space. So the citation could also mean that they did throw out (and simplify) concepts in both areas. Not only from the kernel. So they did balance and optimize the whole system (which is what I want to achieve as well). Unfortunately I never had a chance to meet one of the Unix inventors, so I can't ask them what they really meant and how they did work. But anyways, this is discussing the wrong problem on the wrong level. People out there (and me included) would like to hide or better, easier and more systematically access devices directly connected on the same PCB to a specific UART. And can't. Or can do only with ugly or inefficient solutions. From that we come to this fundamental discussion level because you say that Linux should be a kernel which should only support the minimum. Therefore our requests are rejected, because it could be solved by blowing up the user space. This is IMHO your very valid opinion, but it is not a guideline that I observe when going through the source tree. There are tons of things that could be done in user space (e.g. what are all those I2C device drivers good for? /dev/i2c should suffice to control every device from user space. What is iio good for in the kernel? a library could translate everything into iio interfaces). So this discrepancy is what I criticize because I don't see a basic rule or design principle behind what is acceptable and what is not. If it exists, please point me to it. I am open to learn about that. > >> Most GPS receivers I came across are modules which spit out NMEA >> records with serial 9600 bit/s. Either through RS232 or Bluetooth SPP. There >> may be others, but I don't want to have all problems of the world solved >> at once. > > The kernel lives in the big world, not your personal fiefdom Every contribution initially looks at the area, the contributor is aware of and knows best and does not find a solution using existing hooks. Then discussion starts. But what a contributor can't (and should never) accept is if his problem is simply declared to be a non-problem without providing a *better* alternative solution for it. Better for everybody including the contributor. > > *PLONK* Thanks. Well, I have to apologize that I was not yet aware who hides behind the "one thousand gnomes" e-mail address... Because I judge discussion partners by what they say now and how they help to solve my actual problem for the future (and not what they have done in the past). So you do have a lot of experience with Linux history. And you are amongst the handful of persons who know every detail of the Linux kernel. That is good because it shows that you can really influence how this discussion ends. But sometimes experience could be a little blocking to new ideas and experiences not related to Linux (e.g. close to hardware or embedded design) brought in by newcomers. And it collides with my belief that everything can be done, if people want. Now, how can we help those who want (for IMHO very understandable reasons) to access a specific UART from kernel modules? -- hns
[toc] | [prev] | [next] | [standalone]
| From | Andreas Kemnade <andreas@kemnade.info> |
|---|---|
| Date | 2016-01-19 07:40 +0100 |
| Subject | Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 |
| Message-ID | <qSy7n-3RB-13@gated-at.bofh.it> |
| In reply to | #1311819 |
[Multipart message — attachments visible in raw view] — view raw
On Mon, 18 Jan 2016 22:03:19 +0000
One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> wrote:
> > > Your user space can do it (as most Android does).
> >
> > How can it do it in automatically in a standardized way without need for daemon support?
>
> You don't need to - it can be device specific. In Android it usually is.
> I've never understood why low end devices don't also abstract user space
> descriptions of power control into DT nodes as well as kernel properties ?
>
Well, on these android devices, they are only intended to run android and
have another abstraction layer where you can hide things.
If doing actions on opening or closing a tty should not be implemented in
kernel space, then an alternative I see would be to at least have proper
rfkill support for bluetooth and gps in kernel. Then userspace can at least
can talk to a standardised interface. So userspace just has to implement
generic things.
That would mean for the kernel drivers needed:
W2CBW003/bluetooth:
map the rfkill to just a simple regulator
W2SG0004/gps:
being notified about incoming data
a) the nice way: getting it from the tty/tty_port layer
(but requiring changes at generic kernel code)
or
b) the ugly way:
remux the data line as a gpio and simply look for state
changes during rfkill call (probably only during unblock)
The first characters after power on would probably be lost
toggle a gpio depending on the desired and detected state
Regards,
Andreas
[toc] | [prev] | [next] | [standalone]
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Date | 2016-01-20 20:40 +0100 |
| Subject | Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 |
| Message-ID | <qT6LM-2E2-19@gated-at.bofh.it> |
| In reply to | #1310902 |
On Fri, Jan 15, 2016 at 11:34 PM, Vostrikov Andrey <andrey.vostrikov@cogentembedded.com> wrote: > > Yes, such implementation will help. There is a need for interface like UART BUS that will probe devices without user space. > Serial I/O for input subsystem defines new type of bus and uses dedicated line discipline, but it still unable to start driver by itself and requires call from 'inputattach' to open port, assign line discipline and go to forever wait on 'read'. That was done mainly because almost none of the serial protocols could be auto-probed, so device initialization/setup was moved out of kernel and thus we have the separate line discipline and inputattach utility. Thanks. -- Dmitry
[toc] | [prev] | [next] | [standalone]
| From | Vostrikov Andrey <andrey.vostrikov@cogentembedded.com> |
|---|---|
| Date | 2016-01-20 21:10 +0100 |
| Subject | Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 |
| Message-ID | <qT7eO-33h-5@gated-at.bofh.it> |
| In reply to | #1313462 |
Hi, Dmitry. > On Fri, Jan 15, 2016 at 11:34 PM, Vostrikov Andrey > <andrey.vostrikov@cogentembedded.com> wrote: >> >> Yes, such implementation will help. There is a need for interface like UART BUS that will probe devices without user space. >> Serial I/O for input subsystem defines new type of bus and uses dedicated line discipline, but it still unable to start driver by itself and requires call from 'inputattach' to open port, assign line discipline and go to forever wait on 'read'. > That was done mainly because almost none of the serial protocols could > be auto-probed, so device initialization/setup was moved out of kernel > and thus we have the separate line discipline and inputattach utility. This is understandable for "dummy" devices like mice, that only report input events. But in case there is "intellectual" MCU, that must reply on specific commands with specific response - it could be auto-probed. Especially when it is hardwired. Unfortunately, there is no API to do it. Opening port and attaching line discipline from kernel side does not look good. The only example is '/dev/console', which is implemented that way. > Thanks. -- Best regards, Andrey Vostrikov
[toc] | [prev] | [next] | [standalone]
| From | Mark Rutland <mark.rutland@arm.com> |
|---|---|
| Date | 2016-01-15 17:20 +0100 |
| Subject | Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 |
| Message-ID | <qRfgv-8O-29@gated-at.bofh.it> |
| In reply to | #1310209 |
On Fri, Jan 15, 2016 at 04:05:45PM +0100, H. Nikolaus Schaller wrote:
> Hi Mark,
>
> Am 15.01.2016 um 12:01 schrieb Mark Rutland <mark.rutland@arm.com>:
>
> > On Fri, Jan 15, 2016 at 10:34:51AM +0100, H. Nikolaus Schaller wrote:
> >> Hi Mark,
> >>
> >> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>:
> >>
> >>> On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
> >>>> There is one point still to be solved: the exact style of the DT bindings.
> >>>>
> >>>> We have an idea how a driver can implement two different styles (child node AND phandle)
> >>>> so that it is up to the DTS developer to use the one that best fits into the existing DTS.
> >>>
> >>> From my perspective as a binding maintainer, and as I stated before, the
> >>> child node approach made the most sense and was most consistent with the
> >>
> >>> way we handle other devices.
> >>
> >> I simply don't see that this is the most common way other devices are handled.
> >>
> >> I find many counter-examples which use phandles:
> >> * gpios
> >> * regulators
> >> * iio channels used by other drivers (e.g. iio-hwmon)
> >> * phy devices
> >> * timers
> >> * pwms
> >> * interrupts
> >> * dma
> >
> > As was previously described to you, in these cases phandles are used
> > when these are _resources_ used by another device, not for the main
> > programmer-visible interface to the device.
>
> Ah, I think I finally begin to understand the rule you are following:
>
> If a device's data interface can be seen in user space, this interface
> is sort of a "main interface" and must be modelled in DT by a
> parent-child relationship.
No, you have misunderstood. This has _nothing_ to do with userspace.
This has everything to do with the "programmer's interface" as you would
find documented in a TRM -- effectively where a driver would communicate
with the device (e.g. MMIO/SPI/I2C registers).
[...]
> Now I also think I better understand what you meant by "main interface"
> a while ago.
>
> For me, when looking into a chip data sheet, the main interface is a sometimes
> arbitrary. Or when viewing it through device driver implementors glasses
> I may end up with a different main interface.
>
> From the hardware schematics, I can't read which interface is "main". I can
> only read which components and signals are connected. So the information
> what is "main" must come from somewhere else, but not the hardware.
>
> You appear to have a definition based on Linux user space interfaces
> which is distinct from mine and at least explains why the discussion takes
> so long and we don't come to a common view.
This is nothing to do with userspace.
Admittedly, on a device which has multiple slave interfaces, "main" is
arbitrary. If I've followed correctly, that's not the cae here.
> > Conceptually, A UART slave is far closer to SPI or I2C, where the slave
> > is represented as a sub-node.
>
> Only if you have the goal to describe the data/command path ("main interface")
> in DT.
This is the way devices are described in DT -- walking from the root to
a leaf you follow the path from the CPU to a slave interface.
Some things don't have slave interfaces (e.g. fixed-clocks), but still
need to be referred to, so those still get placed in the DT. There are
arguments to be had w.r.t. their placement, but that's another
discussion entirely.
> I mentioned it several times: USB-PHYs use the phandle approach to attach
> a single PHY to the usb controller, although there is usually some ULPI-"bus"
> interface (12 parallel wires) between. And the PHY is clearly more "slave" than
> the usb controller, isn't it?
Some PHYs have additional interfaces, so their CPU-visible slave
interface is described. This necessitates the phandle reference in the
general case.
> But with phandle, the usb controller is a _resource_ for the PHY. So would
> you say this is wrong?
Not entirely.
> This is the design pattern (for DT and drivers) we have copied for our tty-slave
> proposal.
We have plenty of other ways of describing relationships today. The
existence of one style (and its continued support for ABI reasons) does
not mean that it's a style we want to proliferate.
>
> > I wasn't aware of any instances of timers being referred to by phandle
> > by other devices -- that seems distinctly odd. Where do you see that
> > happening.
>
> I found it in connection with dmtimer / pwm on OMAP3. May be a rare exception
> and that may be a special type of OMAP timers.
I took a quick look and couldn't spot where that happened. I take it
the timer was a "ti,omap3430-timer"? Or have I misunderstood?
What referenced it by phandle? In which dt?
> >> * mcbsp (see e.g. http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-n900.dts#L127)
> >
> > Subsystem type bindings are more of a special case, and regardless the
> > components have nodes in the relevant portions of the DT.
>
> >
> >> * mmc-pwr-seq-simple (which does not even describe a physical piece of hardware)
> >
> > If this is so different, how is it relevant?
>
> It could as well be subnode of the affected mmc interface or mmc-slave, but obviously it
> isn't grouped there, and uses a phandle to refer to its &mmc "master".
>
> Its function is quite similar what we need for our GPS chip: control power sequences
> of a remote device.
That may fit your one particular use-case, but for UART slaves generally
we should have a kernel driver (which can do more than a trivial
power-up), at which point you need a node, and the separate sequence
node is useless.
> >> All of them define the provider in one node. And refer to it by a phandle in another node
> >> where they are used.
> >>
> >> So I see a lot of provider-consumer relationships modeled by phandles but not by child nodes.
> >
> > I agree that provider-consumer type relationships are typically
> > described in this manner.
>
> Ok.
>
> >
> > However, master-slave relationships are not.
>
> It looks as if you see a significant difference between provider-consumer and master-slave
> relationship which I was not sure of which applies to what and where you make the distinction.
>
> By the way: what exactly makes the UART on the SoC side "master" and the UART on the connected
> device a "slave" (except the user-space view)?
Typically a "slave" accepts commands, and won't send commands of its own
accord. This case is admittedly fuzzier given that a UART slave could
send a stream of bytes at any point, but that's data.
The distinction is really that the UART slave won't control other
devices -- you can think of the entire path of the CPU to the UART as
the master.
> UARTs per se have no master-slave roles and are symmetrical (contrary to SPI and I2C where it
> is well defined). Rather, both are formally DTE connected by a null-modem.
>
> This is another substantial difference between UART and I2C/SPI besides addressability.
Sure, except for the fact that the device attached to the UART logically
follows a "slave" role. The rest of the system would be usable without
it, and it assert no control over anything else.
Thanks,
Mark.
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-01-15 20:20 +0100 |
| Subject | Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 |
| Message-ID | <qRi4H-204-27@gated-at.bofh.it> |
| In reply to | #1310247 |
Am 15.01.2016 um 17:12 schrieb Mark Rutland <mark.rutland@arm.com>:
> On Fri, Jan 15, 2016 at 04:05:45PM +0100, H. Nikolaus Schaller wrote:
>> Hi Mark,
>>
>> Am 15.01.2016 um 12:01 schrieb Mark Rutland <mark.rutland@arm.com>:
>>
>>> On Fri, Jan 15, 2016 at 10:34:51AM +0100, H. Nikolaus Schaller wrote:
>>>> Hi Mark,
>>>>
>>>> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>:
>>>>
>>>>> On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote:
>>>>>> There is one point still to be solved: the exact style of the DT bindings.
>>>>>>
>>>>>> We have an idea how a driver can implement two different styles (child node AND phandle)
>>>>>> so that it is up to the DTS developer to use the one that best fits into the existing DTS.
>>>>>
>>>>> From my perspective as a binding maintainer, and as I stated before, the
>>>>> child node approach made the most sense and was most consistent with the
>>>>
>>>>> way we handle other devices.
>>>>
>>>> I simply don't see that this is the most common way other devices are handled.
>>>>
>>>> I find many counter-examples which use phandles:
>>>> * gpios
>>>> * regulators
>>>> * iio channels used by other drivers (e.g. iio-hwmon)
>>>> * phy devices
>>>> * timers
>>>> * pwms
>>>> * interrupts
>>>> * dma
>>>
>>> As was previously described to you, in these cases phandles are used
>>> when these are _resources_ used by another device, not for the main
>>> programmer-visible interface to the device.
>>
>> Ah, I think I finally begin to understand the rule you are following:
>>
>> If a device's data interface can be seen in user space, this interface
>> is sort of a "main interface" and must be modelled in DT by a
>> parent-child relationship.
>
> No, you have misunderstood. This has _nothing_ to do with userspace.
Obviously.
>
> This has everything to do with the "programmer's interface" as you would
> find documented in a TRM -- effectively where a driver would communicate
> with the device (e.g. MMIO/SPI/I2C registers).
What does that have to do with DT descriptions?
I think we agree that as long as the driver can acquire a handle to the interface
chip (UART, I2C controller etc.) through some driver API, it can communicate
(and encapsulate) everything described by the TRM.
I may have a special case that my devices have no programming interface.
GPS simply starts to send NMEA records (ASCII) and Bluetooth protocol is
a user-space daemon.
So the driver does not want to touch the data. Or generate/consume it. Or write
commands (although it could, since it knows the UART driver instance).
For a typical I2C driver this is different. It reads/writes specific registers by telling
the I2C controller (master / parent) to do that on an address specified by the
child DT node.
>
> [...]
>
>> Now I also think I better understand what you meant by "main interface"
>> a while ago.
>>
>> For me, when looking into a chip data sheet, the main interface is a sometimes
>> arbitrary. Or when viewing it through device driver implementors glasses
>> I may end up with a different main interface.
>>
>> From the hardware schematics, I can't read which interface is "main". I can
>> only read which components and signals are connected. So the information
>> what is "main" must come from somewhere else, but not the hardware.
>>
>> You appear to have a definition based on Linux user space interfaces
>> which is distinct from mine and at least explains why the discussion takes
>> so long and we don't come to a common view.
>
> This is nothing to do with userspace.
>
> Admittedly, on a device which has multiple slave interfaces, "main" is
> arbitrary. If I've followed correctly, that's not the cae here.
No, we have a single data path and a single power control line.
So the power control line is the "main" interface (described in the TRM of the chip).
And the driver just needs to know that data is coming out of the chip. It does not
need to know which data.
As said, the purpose of this driver is to control power of the chip by monitoring data
stream, controlling the power control input through a gpio and not to modify or use
the data channel like it would be for SPI or I2C.
For example for a touch screen controller the driver sends commands over I2C
and receives position data. This is translated into input events. Power on/off
is usually another I2C command.
It is a completely different situation and supports my view that devices
connected to UARTs should not necessarily be modeled like I2C and SPI
slaves (where there are explicit master / slave roles).
>
>>> Conceptually, A UART slave is far closer to SPI or I2C, where the slave
>>> is represented as a sub-node.
>>
>> Only if you have the goal to describe the data/command path ("main interface")
>> in DT.
>
> This is the way devices are described in DT -- walking from the root to
> a leaf you follow the path from the CPU to a slave interface.
Ok, that is a new piece of DT design guidelines.
But again which path do you exactly mean? User-Data path? Address path?
Command path? Electrical paths? Power enable path? They may not be the same.
>
> Some things don't have slave interfaces (e.g. fixed-clocks), but still
> need to be referred to, so those still get placed in the DT. There are
> arguments to be had w.r.t. their placement, but that's another
> discussion entirely.
>
>> I mentioned it several times: USB-PHYs use the phandle approach to attach
>> a single PHY to the usb controller, although there is usually some ULPI-"bus"
>> interface (12 parallel wires) between. And the PHY is clearly more "slave" than
>> the usb controller, isn't it?
>
> Some PHYs have additional interfaces, so their CPU-visible slave
> interface is described. This necessitates the phandle reference in the
> general case.
>
>> But with phandle, the usb controller is a _resource_ for the PHY. So would
>> you say this is wrong?
>
> Not entirely.
>
>> This is the design pattern (for DT and drivers) we have copied for our tty-slave
>> proposal.
>
> We have plenty of other ways of describing relationships today. The
> existence of one style (and its continued support for ABI reasons) does
> not mean that it's a style we want to proliferate.
Is there a description about all these style rules? It is really difficult to get them
written down by such lengthy discussions.
>
>>
>>> I wasn't aware of any instances of timers being referred to by phandle
>>> by other devices -- that seems distinctly odd. Where do you see that
>>> happening.
>>
>> I found it in connection with dmtimer / pwm on OMAP3. May be a rare exception
>> and that may be a special type of OMAP timers.
>
> I took a quick look and couldn't spot where that happened. I take it
> the timer was a "ti,omap3430-timer"? Or have I misunderstood?
>
> What referenced it by phandle? In which dt?
Ah, it is "ti,timer" and not general "timer" introduced recently:
<https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt>
My flaw.
>
>>>> * mcbsp (see e.g. http://lxr.free-electrons.com/source/arch/arm/boot/dts/omap3-n900.dts#L127)
>>>
>>> Subsystem type bindings are more of a special case, and regardless the
>>> components have nodes in the relevant portions of the DT.
>>
>>>
>>>> * mmc-pwr-seq-simple (which does not even describe a physical piece of hardware)
>>>
>>> If this is so different, how is it relevant?
>>
>> It could as well be subnode of the affected mmc interface or mmc-slave, but obviously it
>> isn't grouped there, and uses a phandle to refer to its &mmc "master".
>>
>> Its function is quite similar what we need for our GPS chip: control power sequences
>> of a remote device.
>
> That may fit your one particular use-case, but for UART slaves generally
> we should have a kernel driver (which can do more than a trivial
> power-up), at which point you need a node, and the separate sequence
> node is useless.
What we need is similar, the solution is of course not exactly the same.
But why does the DT node have to move (except adding properties)
if the kernel driver does more complex things? It already needs to know
the relationship to the remote device for trivial tasks.
>
>>>> All of them define the provider in one node. And refer to it by a phandle in another node
>>>> where they are used.
>>>>
>>>> So I see a lot of provider-consumer relationships modeled by phandles but not by child nodes.
>>>
>>> I agree that provider-consumer type relationships are typically
>>> described in this manner.
>>
>> Ok.
>>
>>>
>>> However, master-slave relationships are not.
>>
>> It looks as if you see a significant difference between provider-consumer and master-slave
>> relationship which I was not sure of which applies to what and where you make the distinction.
>>
>> By the way: what exactly makes the UART on the SoC side "master" and the UART on the connected
>> device a "slave" (except the user-space view)?
>
> Typically a "slave" accepts commands, and won't send commands of its own
> accord. This case is admittedly fuzzier given that a UART slave could
> send a stream of bytes at any point, but that's data.
It could not only, it does in our case. Which is the main reason why we need a dedicated
driver.
And there are no standardized UART slave commands. Well, GSM07.07 to some extent.
But that is a protocol handled by user space daemons. And commands are completely
mixed with data so that there are escape characters etc.
>
> The distinction is really that the UART slave won't control other
> devices -- you can think of the entire path of the CPU to the UART as
> the master.
What if there is a plain old terminal device hard wired to the UART?
Here, I would see the user typing commands as "the master" :)
And the data flow is from device to UART to CPU.
Or if the device is an MCU that is connected to a getty login port?
So IMHO we have introduced much of the problem by thinking in "UART slave" categories.
UART seems indeed to be a different beast, because it is more a "partner" thing.
More like a subsystem (maybe audio/sound?) connected to the main CPU by means
of the UART.
>
>> UARTs per se have no master-slave roles and are symmetrical (contrary to SPI and I2C where it
>> is well defined). Rather, both are formally DTE connected by a null-modem.
>>
>> This is another substantial difference between UART and I2C/SPI besides addressability.
>
> Sure, except for the fact that the device attached to the UART logically
> follows a "slave" role. The rest of the system would be usable without
> it, and it assert no control over anything else.
Ok, if you take this view, it is indeed sort of a subordinate. Nothing happens if the
user does not press the power-on button :)
Also to be considered is that the UART is also unusable without the device being
powered on or a partner device being connected.
But we are back to discuss solutions and details and not requirements which makes
this a non-ending story because it is more confusing than bringing it to the key factors.
And please give me some links where all these DT styles and rules are written down.
It would make it easier to develop something that fits, without lengthy discussions.
Or to separately discuss rules.
And, may I repeat my question what I can do to convince you to accept a practical
solution? What could go wrong if you would accept the phandle approach? Which
known UART topic would it not solve or make impossible to solve?
BR and thanks,
Nikolaus
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2016-01-15 20:50 +0100 |
| Subject | Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 |
| Message-ID | <qRixI-2cl-17@gated-at.bofh.it> |
| In reply to | #1308750 |
On Fri 2016-01-15 10:34:51, H. Nikolaus Schaller wrote: > Hi Mark, > > Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>: > > > On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote: > >> Hi Tomeu, > >> > >> Am 12.01.2016 um 14:06 schrieb Tomeu Vizoso <tomeu@tomeuvizoso.net>: > >> > >>> On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote: > >>>> Hi all, > >>>> here is version 4 of my "UART slave device" patch set, previously > >>>> known as "tty slave devices". > >>> > >>> Hi Neil, > >>> > >>> do you (or someone else) have plans to continue this work in the short > >>> or medium term? > >> > >> yes, there is something in our upstreaming pipeline. This one works for us on top of 4.4.0: > >> > >> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-tty-slave2-v4> > >> > >> There is one point still to be solved: the exact style of the DT bindings. > >> > >> We have an idea how a driver can implement two different styles (child node AND phandle) > >> so that it is up to the DTS developer to use the one that best fits into the existing DTS. > > > > From my perspective as a binding maintainer, and as I stated before, the > > child node approach made the most sense and was most consistent with the > > > way we handle other devices. > > I simply don't see that this is the most common way other devices > are handled. You promised to shut up once maintainers speak, that happened, and you did not shut up. Just do it now. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [next] | [standalone]
| From | "H. Nikolaus Schaller" <hns@goldelico.com> |
|---|---|
| Date | 2016-01-15 21:40 +0100 |
| Subject | Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4 |
| Message-ID | <qRjk6-2Kk-5@gated-at.bofh.it> |
| In reply to | #1310413 |
Am 15.01.2016 um 20:40 schrieb Pavel Machek <pavel@ucw.cz>: > On Fri 2016-01-15 10:34:51, H. Nikolaus Schaller wrote: >> Hi Mark, >> >> Am 13.01.2016 um 20:15 schrieb Mark Rutland <mark.rutland@arm.com>: >> >>> On Tue, Jan 12, 2016 at 02:28:00PM +0100, H. Nikolaus Schaller wrote: >>>> Hi Tomeu, >>>> >>>> Am 12.01.2016 um 14:06 schrieb Tomeu Vizoso <tomeu@tomeuvizoso.net>: >>>> >>>>> On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote: >>>>>> Hi all, >>>>>> here is version 4 of my "UART slave device" patch set, previously >>>>>> known as "tty slave devices". >>>>> >>>>> Hi Neil, >>>>> >>>>> do you (or someone else) have plans to continue this work in the short >>>>> or medium term? >>>> >>>> yes, there is something in our upstreaming pipeline. This one works for us on top of 4.4.0: >>>> >>>> <http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-tty-slave2-v4> >>>> >>>> There is one point still to be solved: the exact style of the DT bindings. >>>> >>>> We have an idea how a driver can implement two different styles (child node AND phandle) >>>> so that it is up to the DTS developer to use the one that best fits into the existing DTS. >>> >>> From my perspective as a binding maintainer, and as I stated before, the >>> child node approach made the most sense and was most consistent with the >> >>> way we handle other devices. >> >> I simply don't see that this is the most common way other devices >> are handled. > > You promised to shut up once maintainers speak, that happened, and you > did not shut up. Just do it now. Nobody has asked for your unqualified and not helpful comments. So please shut up yourself and stop to disturb Free Software projects.
[toc] | [prev] | [next] | [standalone]
| From | NeilBrown <neil@brown.name> |
|---|---|
| Date | 2016-01-12 22:30 +0100 |
| Message-ID | <qQeFQ-6D6-31@gated-at.bofh.it> |
| In reply to | #1307386 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, Jan 13 2016, Tomeu Vizoso wrote: > On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote: >> Hi all, >> here is version 4 of my "UART slave device" patch set, previously >> known as "tty slave devices". > > Hi Neil, > > do you (or someone else) have plans to continue this work in the short > or medium term? > I personally have no current plans. Too many other interesting things to do and my interest in the hardware is in the waning phase. NeilBrown
[toc] | [prev] | [next] | [standalone]
| From | Pavel Machek <pavel@ucw.cz> |
|---|---|
| Date | 2016-01-13 20:10 +0100 |
| Message-ID | <qQyXU-41l-21@gated-at.bofh.it> |
| In reply to | #1307845 |
On Wed 2016-01-13 08:28:24, NeilBrown wrote: > On Wed, Jan 13 2016, Tomeu Vizoso wrote: > > > On 11 May 2015 at 03:56, NeilBrown <neil@brown.name> wrote: > >> Hi all, > >> here is version 4 of my "UART slave device" patch set, previously > >> known as "tty slave devices". > > > > Hi Neil, > > > > do you (or someone else) have plans to continue this work in the short > > or medium term? > > > > I personally have no current plans. Too many other interesting things > to do and my interest in the hardware is in the waning phase. Can we convince you to play with N900? Your python stuff should still work, it has keyboard, and we have calls working now ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[toc] | [prev] | [standalone]
Page 3 of 3 — ← Prev page 1 2 [3]
Back to top | Article view | linux.kernel
csiph-web