Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi all, I will reverse a part of this e-mail to make replying easier. On Fri, Aug 28, 2015 at 1:04 PM, Pavel Machek wrote: >> Please have a look into our RFC implementation and study it carefully >> to learn why it is the better (IMHO more flexible, easier to maintain, more >> modular) approach. Even if you don’t like phandles. > > It was also NAKed by device tree maintainers. This may be true, I can't recall those specific mails... > You promised to shut up. But this is uncalled for. IIRC there was, indeed, a long technical discussion about how to connect the Bluetooth chip to the 'UART'. I've seen Neil patches, and I've seen patches by Nikolaus. Both appear to have their problems. I think it's fair to: - Listen carefully to all arguments. - Have a benevolent dictator, which we have, look into the problem - Only 'shut up' after a thorough technical analysis has been made about both approaches to the problem. Both may have their merit in a number of ways. Don't just close your eyes, put your fingers in your ears and say 'I can't hear you!'. We are all adults, or at least, we should be in behaviour. The Linux system has grown so much _beacuse_ of people working together. Calling each other names and exiling them will _not_ solve the problem. Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
> > asking "device tree maintainer opinion", and then just simply ignoring > > it when he does not like it, and then making promises he did not keep. > > Which promises did I not keep? Please be specific, instead of You promised to shut up. > Please have a look into our RFC implementation and study it carefully > to learn why it is the better (IMHO more flexible, easier to maintain, more > modular) approach. Even if you don’t like phandles. It was also NAKed by device tree maintainers. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi Pavel, Am 28.08.2015 um 09:02 schrieb Pavel Machek : > Hi! > >> we (the developers of the hardware) have proposed an alternative >> approach to Neil’s implementation - for the same device and solving >> the same problem (notifying tty open/close and uart activity to the >> slave device driver), but differently. >> >> See: >> https://lkml.org/lkml/2015/6/28/91 >> >> Discussion has not yet settled on which approach is better. So your >> opinion of comparing both is welcome. > > Actually, yes, discussion has settled, agreeing that phandle reference > for the uart is a bad idea, Nikolaus just refuses to listen to anyone, no, I only refuse to listen to you. You are neither maintainer for any subsystem that is involved nor have you contributed technical arguments pro/con and it appears to me that you refuse to listen to my argumentation. > asking "device tree maintainer opinion", and then just simply ignoring > it when he does not like it, and then making promises he did not keep. Which promises did I not keep? Please be specific, instead of insulting. I bring up this alternative again, since I get the impression that most readers are simply not aware of *both* alternative proposals. > Please don't stall patches just because of that. Please provide better arguments and don’t spread FUD. Please have a look into our RFC implementation and study it carefully to learn why it is the better (IMHO more flexible, easier to maintain, more modular) approach. Even if you don’t like phandles. > > Best regards, > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html BR, Nikolaus -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi! > we (the developers of the hardware) have proposed an alternative > approach to Neil’s implementation - for the same device and solving > the same problem (notifying tty open/close and uart activity to the > slave device driver), but differently. > > See: > https://lkml.org/lkml/2015/6/28/91 > > Discussion has not yet settled on which approach is better. So your > opinion of comparing both is welcome. Actually, yes, discussion has settled, agreeing that phandle reference for the uart is a bad idea, Nikolaus just refuses to listen to anyone, asking "device tree maintainer opinion", and then just simply ignoring it when he does not like it, and then making promises he did not keep. Please don't stall patches just because of that. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Gta04-owner] [PATCH 0/4] UART slave device support - version 4
Hi Linus,
Am 12.08.2015 um 01:20 schrieb NeilBrown :
> On Fri, 7 Aug 2015 15:01:47 +0200 Linus Walleij
> wrote:
>
>> Hi Neil,
>>
>> first, this is a *VERY* interesting and much needed patch series,
>> I intend to look closer at it, and if possible test it with some
>> (heh) board file device. Would be happy of you put me on CC for these.
>>
>> On Mon, May 11, 2015 at 3:56 AM, NeilBrown wrote:
>>
>>> When a device is connected to a UART via RS-232 (or similar), there
>>> is a DTR line that can be used for power management, and other "modem
>>> control" lines.
>>>
>>> On an embedded board, it is very likely that there is no "DTR", and
>>> any power management need to be done using some completely separate
>>> mechanism.
>>>
>>> So these "slaves" are really just for devices permanently attached to
>>> UARTs without a full "RS-232" (or similar) connection. The driver
>>> does all the extra control beyond Tx/Rx.
>>
>> What is usually happening (and I have seen it in a few places) is that
>> the SoC has *one* fully featured RS232 with CTS/RTS and even
>> DTS,DCD,RI and other esoterica, which is intended to be connected to a
>> host serial port or so, for example if this SoC is to act as a modem
>> or a fax machine, or if it is to drive one.
>>
>> Then they often have a few more UART blocks, usually identical, which
>> only have RxD+TxD available, so they are "just" UARTs.
>>
>> To complicate things further, you may wonder what happened with
>> the CTS/RTS (etc) signals from the other blocks. Usually they are there
>> in the silicon but just routed to dead ends.
>>
>> To complicate it even further, usually all these pins are placed under
>> pin control multiplexing, so in an actual electronic design, the
>> system will mux out CTS/RTS (etc) from the fully featured RS232
>> blocks and only use them as UARTs anyways.
>>
>> Then there are those who created real simple RxD/TxD-only UARTs
>> ("yeah lets dump this RS232 legacy crap" / "yeah yeah")
>> and then realized they want to drive modems ("oh crap, it seemed
>> like a good idea at the time"). Then they usually take
>> two GPIO pins for CTS/RTS and drive them as GPIOs using
>> software and you have a cheap 4-line modem line. This is what
>> drivers/tty/serial/serial_mctrl_gpio.c is for if you wondered.
>>
>>> I've tested this set and it seems to work ... except that something
>>> is sadly broken with bluetooth support in 4.1-rc1 so I've only really
>>> tested the GPS driver. I guess it is time to rebase to -rc3.
>>
>> You have a hardware taget I see. Which one?
>
> GTA04 (www.gta04.org - openmoko successor).
>
> 3 uarts on OMAP3 are wired: one as RS-232 for console, one to bluetooth
> half of a wifi/bluetooth module, and one to a GPS.
>
> For the GPS, I just want to power on/off when the TTY is opened/closed,
> but the power-on sequence is non-trivial as both "turn on" and
> "turn-off' toggle the same line, so I need to be able to detect current
> state.
>
> For the bluetooth, the power is a (shared) regulator. As well as
> power-on when the TTY is opened, I'd like regulator to be turned of
> when I "hciconfig down" - even though the TTY is still open.
> I did a patch a while ago which hooked in to hci_uart_{open,close} to
> make this work, but it isn't a really good patch.
>
> It would be nice to hide the TTY from user-space in the bluetooth case,
> and have the "hciattach" happen in the kernel, but I think hciattach
> does extra initialisation...
>
> NeilBrown
we (the developers of the hardware) have proposed an alternative
approach to Neil’s implementation - for the same device and solving
the same problem (notifying tty open/close and uart activity to the
slave device driver), but differently.
See:
https://lkml.org/lkml/2015/6/28/91
Discussion has not yet settled on which approach is better. So your
opinion of comparing both is welcome.
BR,
Nikolaus
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
