Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
On Wed, Jul 9, 2014 at 2:23 PM, One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: I like the sound of going to the standard ttyS notation and only providing ports for ones that exist, but is this userspace-visible ttyS is 8250 compatible UARTS. If the Samsung is not an 8250 compatible UART then it doesn't belong as ttyS from the kernel perspective. OK, thanks for pointing that out. So we stick with the ttySAC namespace. And by doing that, and sticking to the existing and documented behaviour, it seems like we have already addressed Russells's concern: The problem you're raising is very much the same problem you have when there are multiple USB serial devices connected to the machine - you just get a bunch of /dev/ttyUSB* devices which are unordered (they can change on each boot, or change order if you disconnect and reconnect them.) In this case, we have a dedicated namespace and the path information is already fully encoded in the device name. The order and number of ports are fixed, they can't be disconnected and reconnected. There is no real risk of an additional serial controller driver coming to play in the ttySAC namespace. So I think Tomasz's approach is good - although I haven't looked at the code in detail. Thanks Daniel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
I like the sound of going to the standard ttyS notation and only providing ports for ones that exist, but is this userspace-visible ttyS is 8250 compatible UARTS. If the Samsung is not an 8250 compatible UART then it doesn't belong as ttyS from the kernel perspective. How your udev handles it is up to you. Alan -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
Hi,
How can we move forward here?
On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa t.f...@samsung.com wrote:
- basically Samsung UART already has its own namespace (ttySAC) and the
order inside it is well-defined - instance ID shall be the hardware
instance number as specified by documentation. The ports vary in certain
aspects and the ID is important knowledge of the driver. The problem
here was broken implementation of assigning IDs based on probe order,
which worked only because on all Exynos platforms all ports have been
always registered (which we want to change now and keep unused ones
disabled in DT),
Yes, the kernel help text documents this quite well:
config SERIAL_SAMSUNG
tristate Samsung SoC serial support
depends on PLAT_SAMSUNG
select SERIAL_CORE
help
Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
providing /dev/ttySAC0, 1 and 2 (note, some machines may not
provide all of these ports, depending on how the serial port
pins are configured.
- we already have a lot of userspace depending on the aforementioned
ttySAC namespace and proper ordering of instances there. While I believe
the proper solution as of today would be to go back to standard ttyS
namespace and make userspace use a smarter way of identifying the
instances (e.g. by path or id, as you suggested), I don't think this
will make anyone's life easier with current assumptions,
I like the sound of going to the standard ttyS notation and only
providing ports for ones that exist, but is this userspace-visible
naming change OK? You could argue that userspace that relies on fixed
device paths is a bit broken, but that argument would be a bit cloudy
given the kernel documentation for the ttySAC devices above.
- correct me if I'm wrong, but I don't think the
/dev/serial/by-{path,id} would be handled in kernel's console= parameter.
That's right, that problem is left to the user, but at least we'd be
consistent with other SoCs (and open to generic solutions to that
inconvenience).
Daniel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
On 08.07.2014 10:32, Daniel Drake wrote:
Hi,
How can we move forward here?
Greg, Jiri, what do you think?
On Thu, Jun 26, 2014 at 1:02 PM, Tomasz Figa t.f...@samsung.com wrote:
- basically Samsung UART already has its own namespace (ttySAC) and the
order inside it is well-defined - instance ID shall be the hardware
instance number as specified by documentation. The ports vary in certain
aspects and the ID is important knowledge of the driver. The problem
here was broken implementation of assigning IDs based on probe order,
which worked only because on all Exynos platforms all ports have been
always registered (which we want to change now and keep unused ones
disabled in DT),
Yes, the kernel help text documents this quite well:
config SERIAL_SAMSUNG
tristate Samsung SoC serial support
depends on PLAT_SAMSUNG
select SERIAL_CORE
help
Support for the on-chip UARTs on the Samsung S3C24XX series CPUs,
providing /dev/ttySAC0, 1 and 2 (note, some machines may not
provide all of these ports, depending on how the serial port
pins are configured.
- we already have a lot of userspace depending on the aforementioned
ttySAC namespace and proper ordering of instances there. While I believe
the proper solution as of today would be to go back to standard ttyS
namespace and make userspace use a smarter way of identifying the
instances (e.g. by path or id, as you suggested), I don't think this
will make anyone's life easier with current assumptions,
I like the sound of going to the standard ttyS notation and only
providing ports for ones that exist, but is this userspace-visible
naming change OK? You could argue that userspace that relies on fixed
device paths is a bit broken, but that argument would be a bit cloudy
given the kernel documentation for the ttySAC devices above.
I'd say such argument would be completely invalid as this is most likely
almost all of the userspace for Samsung SoCs and, in addition to this,
quite a lot of firmware which pass console=ttySACx through command line.
- correct me if I'm wrong, but I don't think the
/dev/serial/by-{path,id} would be handled in kernel's console= parameter.
That's right, that problem is left to the user, but at least we'd be
consistent with other SoCs (and open to generic solutions to that
inconvenience).
And so the point of this series is to make this no longer be left to the
user, making hardware UART 2 always UART 2 (which is supposed to be the
current behavior, but not always due to broken implementation) which is
completely orthogonal to raised issues.
Regardless of whether we stick to ttySAC or move back to ttyS, we still
need a deterministic way to assign the ID (even for internal driver
purposes) and that's why this series adds parsing of aliases. No user
visible behavior should be changed by this series.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Deterministic UART numbering on Samsung SoCs
Current Samsung UART driver relies on probe order of particular samsung-uart instances, which makes it impossible to get proper initialization of ports when not all ports are available on board, not even saying of deterministic device naming. This series intends to fix this situation by adding support to parse aliases from device tree and use them to assign instance IDs to particular port instances. Tested on Exynos4412-based Trats2 board: 1) without patch 3/3 adding aliases, 2) with patch 3/3 with all UART ports enabled, 3) with patch 3/3 with selected UART ports disabled. Tomasz Figa (3): Documentation: devicetree: Update samsung UART bindings serial: samsung: Consider DT alias when probing ports ARM: dts: SAMSUNG: Add aliases of UART nodes .../devicetree/bindings/serial/samsung_uart.txt| 52 +++--- arch/arm/boot/dts/exynos3250.dtsi | 2 + arch/arm/boot/dts/exynos4.dtsi | 12 +++-- arch/arm/boot/dts/exynos5.dtsi | 15 +-- arch/arm/boot/dts/exynos5260.dtsi | 4 ++ arch/arm/boot/dts/exynos5410.dtsi | 6 +++ arch/arm/boot/dts/exynos5440.dtsi | 6 ++- arch/arm/boot/dts/s3c2416.dtsi | 6 ++- arch/arm/boot/dts/s3c24xx.dtsi | 9 ++-- arch/arm/boot/dts/s3c64xx.dtsi | 4 ++ drivers/tty/serial/samsung.c | 13 -- 11 files changed, 106 insertions(+), 23 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
On Thu, Jun 26, 2014 at 01:24:32PM +0200, Tomasz Figa wrote:
Current Samsung UART driver relies on probe order of particular
samsung-uart instances, which makes it impossible to get proper
initialization of ports when not all ports are available on board,
not even saying of deterministic device naming.
This series intends to fix this situation by adding support to parse
aliases from device tree and use them to assign instance IDs to
particular port instances.
How about instead exporting the path/id information so that userspace
can create /dev/serial/by-{path,id}/... for internal devices instead?
The problem you're raising is very much the same problem you have when
there are multiple USB serial devices connected to the machine - you
just get a bunch of /dev/ttyUSB* devices which are unordered (they can
change on each boot, or change order if you disconnect and reconnect
them.)
/dev/serial/by-{path,id}/ allows for a much more stable path.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Deterministic UART numbering on Samsung SoCs
On 26.06.2014 13:39, Russell King - ARM Linux wrote:
On Thu, Jun 26, 2014 at 01:24:32PM +0200, Tomasz Figa wrote:
Current Samsung UART driver relies on probe order of particular
samsung-uart instances, which makes it impossible to get proper
initialization of ports when not all ports are available on board,
not even saying of deterministic device naming.
This series intends to fix this situation by adding support to parse
aliases from device tree and use them to assign instance IDs to
particular port instances.
How about instead exporting the path/id information so that userspace
can create /dev/serial/by-{path,id}/... for internal devices instead?
The problem you're raising is very much the same problem you have when
there are multiple USB serial devices connected to the machine - you
just get a bunch of /dev/ttyUSB* devices which are unordered (they can
change on each boot, or change order if you disconnect and reconnect
them.)
/dev/serial/by-{path,id}/ allows for a much more stable path.
The problem being solved has slightly different constraints than the one
with USB serials you mentioned:
- basically Samsung UART already has its own namespace (ttySAC) and the
order inside it is well-defined - instance ID shall be the hardware
instance number as specified by documentation. The ports vary in certain
aspects and the ID is important knowledge of the driver. The problem
here was broken implementation of assigning IDs based on probe order,
which worked only because on all Exynos platforms all ports have been
always registered (which we want to change now and keep unused ones
disabled in DT),
- we already have a lot of userspace depending on the aforementioned
ttySAC namespace and proper ordering of instances there. While I believe
the proper solution as of today would be to go back to standard ttyS
namespace and make userspace use a smarter way of identifying the
instances (e.g. by path or id, as you suggested), I don't think this
will make anyone's life easier with current assumptions,
- correct me if I'm wrong, but I don't think the
/dev/serial/by-{path,id} would be handled in kernel's console= parameter.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
