* Re: BCM2048 bluetooth connected over OMAP serial
@ 2014-12-10 20:56 ` Pavel Machek
0 siblings, 0 replies; 20+ messages in thread
From: Pavel Machek @ 2014-12-10 20:56 UTC (permalink / raw)
To: Mark Rutland
Cc: Arnd Bergmann, linux-arm-kernel@lists.infradead.org,
pali.rohar@gmail.com, sre@debian.org, sre@ring0.de, kernel list,
linux-omap@vger.kernel.org, tony@atomide.com, khilman@kernel.org,
aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com,
devicetree@vger.kernel.org, robh+dt@kernel.org, Pawel Moll,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org
On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
> On Wed, Dec 10, 2014 at 05:02:42PM +0000, Arnd Bergmann wrote:
> > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
> > >
> > > So, there's bluetooth chip that's connected to the SoC by UART and some
> > > GPIOs. What would be right representation in the device tree?
> > > Something like this?
> > >
> > > bluetooth {
> > > compatible = "broadcom,bcm2048";
> > > uart = <&uart2>;
> > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
> > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */
> > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */
> > > chip-type = >;
> > > bt-sysclk = <2>;
> > > reset-gpio-shared = <0>;
> > > };
> > >
> > > Is there some way to prevent OMAP tty driver from binding to the
> > > device and exporting the device to userspace?
> >
> > I think from the driver perspective, you want this to be a tty line
> > discipline rather than a driver that attaches to the physical
> > uart.
> >
> > For the DT representation, I fear we haven't got a precedent. A uart
> > phandle sounds reasonable, but there might be other ways to do it
> > and we should consider if there are better alternatives. It could
> > possibly be a child node of the uart, but that would require other
> > infrastructure in the kernel because we don't currently create
> > devices for those.
>
> I think the child node is the way to go; that would match what we do for
> I2C and SPI. We might need new infrastructure, but I don't think we
> should treat this differently simlpy because we don't have that yet.
Well, uart in this case looks more like a GPIO than an I2C (no
addressing, just few wires). And we do phandle for GPIOs.
Actually, the chip also has PCM, analog audio, and "pc compatible?"
connections, plus some connection to WIFI. So we may need more
phandles there....
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 20+ messages in thread* BCM2048 bluetooth connected over OMAP serial
@ 2014-12-10 20:56 ` Pavel Machek
0 siblings, 0 replies; 20+ messages in thread
From: Pavel Machek @ 2014-12-10 20:56 UTC (permalink / raw)
To: linux-arm-kernel
On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
> On Wed, Dec 10, 2014 at 05:02:42PM +0000, Arnd Bergmann wrote:
> > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
> > >
> > > So, there's bluetooth chip that's connected to the SoC by UART and some
> > > GPIOs. What would be right representation in the device tree?
> > > Something like this?
> > >
> > > bluetooth {
> > > compatible = "broadcom,bcm2048";
> > > uart = <&uart2>;
> > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
> > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */
> > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */
> > > chip-type = >;
> > > bt-sysclk = <2>;
> > > reset-gpio-shared = <0>;
> > > };
> > >
> > > Is there some way to prevent OMAP tty driver from binding to the
> > > device and exporting the device to userspace?
> >
> > I think from the driver perspective, you want this to be a tty line
> > discipline rather than a driver that attaches to the physical
> > uart.
> >
> > For the DT representation, I fear we haven't got a precedent. A uart
> > phandle sounds reasonable, but there might be other ways to do it
> > and we should consider if there are better alternatives. It could
> > possibly be a child node of the uart, but that would require other
> > infrastructure in the kernel because we don't currently create
> > devices for those.
>
> I think the child node is the way to go; that would match what we do for
> I2C and SPI. We might need new infrastructure, but I don't think we
> should treat this differently simlpy because we don't have that yet.
Well, uart in this case looks more like a GPIO than an I2C (no
addressing, just few wires). And we do phandle for GPIOs.
Actually, the chip also has PCM, analog audio, and "pc compatible?"
connections, plus some connection to WIFI. So we may need more
phandles there....
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: BCM2048 bluetooth connected over OMAP serial
2014-12-10 20:56 ` Pavel Machek
@ 2014-12-10 22:50 ` sre@debian.org
-1 siblings, 0 replies; 20+ messages in thread
From: sre@debian.org @ 2014-12-10 22:50 UTC (permalink / raw)
To: Pavel Machek
Cc: Mark Rutland, Arnd Bergmann, linux-arm-kernel@lists.infradead.org,
pali.rohar@gmail.com, kernel list, linux-omap@vger.kernel.org,
tony@atomide.com, khilman@kernel.org, aaro.koskinen@iki.fi,
ivo.g.dimitrov.75@gmail.com, devicetree@vger.kernel.org,
robh+dt@kernel.org, Pawel Moll, ijc+devicetree@hellion.org.uk,
galak@codeaurora.org
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
Hi,
On Wed, Dec 10, 2014 at 09:56:22PM +0100, Pavel Machek wrote:
> On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
> > On Wed, Dec 10, 2014 at 05:02:42PM +0000, Arnd Bergmann wrote:
> > > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
> > > >
> > > > So, there's bluetooth chip that's connected to the SoC by UART and some
> > > > GPIOs. What would be right representation in the device tree?
> > > > Something like this?
> > > >
> > > > bluetooth {
> > > > compatible = "broadcom,bcm2048";
> > > > uart = <&uart2>;
> > > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
> > > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */
> > > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */
> > > > chip-type = >;
> > > > bt-sysclk = <2>;
> > > > reset-gpio-shared = <0>;
> > > > };
> > > >
> > > > Is there some way to prevent OMAP tty driver from binding to the
> > > > device and exporting the device to userspace?
> > >
> > > I think from the driver perspective, you want this to be a tty line
> > > discipline rather than a driver that attaches to the physical
> > > uart.
> > >
> > > For the DT representation, I fear we haven't got a precedent. A uart
> > > phandle sounds reasonable, but there might be other ways to do it
> > > and we should consider if there are better alternatives. It could
> > > possibly be a child node of the uart, but that would require other
> > > infrastructure in the kernel because we don't currently create
> > > devices for those.
> >
> > I think the child node is the way to go; that would match what we do for
> > I2C and SPI. We might need new infrastructure, but I don't think we
> > should treat this differently simlpy because we don't have that yet.
>
> Well, uart in this case looks more like a GPIO than an I2C (no
> addressing, just few wires). And we do phandle for GPIOs.
Right and the devices use I2C for full communication and GPIOs as
helpers. I guess UART counts as full communication and not as helper.
phandle vs child node is not a matter of adressing and btw where is
the difference between "5th gpio on 1st gpio controller" and "5th
address on 1st i2c controller"?
> Actually, the chip also has PCM, analog audio, and "pc compatible?"
> connections, plus some connection to WIFI. So we may need more
> phandles there....
This is much harder to solve. I think we don't have a DT binding for
a device, which uses two communication interfaces as the bcm2048
(uart & i2c). OTOH we may just add a slave device for the fm-radio
part like this:
uart {
bcm2048 {
stuff;
};
};
i2c {
bcm2048-radio {
master = <&bcm2048>;
};
};
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread* BCM2048 bluetooth connected over OMAP serial
@ 2014-12-10 22:50 ` sre@debian.org
0 siblings, 0 replies; 20+ messages in thread
From: sre@debian.org @ 2014-12-10 22:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On Wed, Dec 10, 2014 at 09:56:22PM +0100, Pavel Machek wrote:
> On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
> > On Wed, Dec 10, 2014 at 05:02:42PM +0000, Arnd Bergmann wrote:
> > > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
> > > >
> > > > So, there's bluetooth chip that's connected to the SoC by UART and some
> > > > GPIOs. What would be right representation in the device tree?
> > > > Something like this?
> > > >
> > > > bluetooth {
> > > > compatible = "broadcom,bcm2048";
> > > > uart = <&uart2>;
> > > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
> > > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */
> > > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */
> > > > chip-type = >;
> > > > bt-sysclk = <2>;
> > > > reset-gpio-shared = <0>;
> > > > };
> > > >
> > > > Is there some way to prevent OMAP tty driver from binding to the
> > > > device and exporting the device to userspace?
> > >
> > > I think from the driver perspective, you want this to be a tty line
> > > discipline rather than a driver that attaches to the physical
> > > uart.
> > >
> > > For the DT representation, I fear we haven't got a precedent. A uart
> > > phandle sounds reasonable, but there might be other ways to do it
> > > and we should consider if there are better alternatives. It could
> > > possibly be a child node of the uart, but that would require other
> > > infrastructure in the kernel because we don't currently create
> > > devices for those.
> >
> > I think the child node is the way to go; that would match what we do for
> > I2C and SPI. We might need new infrastructure, but I don't think we
> > should treat this differently simlpy because we don't have that yet.
>
> Well, uart in this case looks more like a GPIO than an I2C (no
> addressing, just few wires). And we do phandle for GPIOs.
Right and the devices use I2C for full communication and GPIOs as
helpers. I guess UART counts as full communication and not as helper.
phandle vs child node is not a matter of adressing and btw where is
the difference between "5th gpio on 1st gpio controller" and "5th
address on 1st i2c controller"?
> Actually, the chip also has PCM, analog audio, and "pc compatible?"
> connections, plus some connection to WIFI. So we may need more
> phandles there....
This is much harder to solve. I think we don't have a DT binding for
a device, which uses two communication interfaces as the bcm2048
(uart & i2c). OTOH we may just add a slave device for the fm-radio
part like this:
uart {
bcm2048 {
stuff;
};
};
i2c {
bcm2048-radio {
master = <&bcm2048>;
};
};
-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141210/eb7b900d/attachment.sig>
^ permalink raw reply [flat|nested] 20+ messages in thread[parent not found: <20141210225036.GA5585-SfvFxonMDyemK9LvCR3Hrw@public.gmane.org>]
* Re: BCM2048 bluetooth connected over OMAP serial
2014-12-10 22:50 ` sre@debian.org
(?)
@ 2014-12-11 22:10 ` Belisko Marek
-1 siblings, 0 replies; 20+ messages in thread
From: Belisko Marek @ 2014-12-11 22:10 UTC (permalink / raw)
To: sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org
Cc: Pavel Machek, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
Pawel Moll, Arnd Bergmann,
khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org,
aaro.koskinen-X3B1VOXEql0@public.gmane.org, kernel list,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
pali.rohar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Neil Brown send series which implement what was suggested in previous posts:
https://lkml.org/lkml/2014/12/11/454
On Wed, Dec 10, 2014 at 11:50 PM, sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hi,
>
> On Wed, Dec 10, 2014 at 09:56:22PM +0100, Pavel Machek wrote:
>> On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
>> > On Wed, Dec 10, 2014 at 05:02:42PM +0000, Arnd Bergmann wrote:
>> > > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
>> > > >
>> > > > So, there's bluetooth chip that's connected to the SoC by UART and some
>> > > > GPIOs. What would be right representation in the device tree?
>> > > > Something like this?
>> > > >
>> > > > bluetooth {
>> > > > compatible = "broadcom,bcm2048";
>> > > > uart = <&uart2>;
>> > > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
>> > > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */
>> > > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */
>> > > > chip-type = >;
>> > > > bt-sysclk = <2>;
>> > > > reset-gpio-shared = <0>;
>> > > > };
>> > > >
>> > > > Is there some way to prevent OMAP tty driver from binding to the
>> > > > device and exporting the device to userspace?
>> > >
>> > > I think from the driver perspective, you want this to be a tty line
>> > > discipline rather than a driver that attaches to the physical
>> > > uart.
>> > >
>> > > For the DT representation, I fear we haven't got a precedent. A uart
>> > > phandle sounds reasonable, but there might be other ways to do it
>> > > and we should consider if there are better alternatives. It could
>> > > possibly be a child node of the uart, but that would require other
>> > > infrastructure in the kernel because we don't currently create
>> > > devices for those.
>> >
>> > I think the child node is the way to go; that would match what we do for
>> > I2C and SPI. We might need new infrastructure, but I don't think we
>> > should treat this differently simlpy because we don't have that yet.
>>
>> Well, uart in this case looks more like a GPIO than an I2C (no
>> addressing, just few wires). And we do phandle for GPIOs.
>
> Right and the devices use I2C for full communication and GPIOs as
> helpers. I guess UART counts as full communication and not as helper.
>
> phandle vs child node is not a matter of adressing and btw where is
> the difference between "5th gpio on 1st gpio controller" and "5th
> address on 1st i2c controller"?
>
>> Actually, the chip also has PCM, analog audio, and "pc compatible?"
>> connections, plus some connection to WIFI. So we may need more
>> phandles there....
>
> This is much harder to solve. I think we don't have a DT binding for
> a device, which uses two communication interfaces as the bcm2048
> (uart & i2c). OTOH we may just add a slave device for the fm-radio
> part like this:
>
> uart {
> bcm2048 {
> stuff;
> };
> };
>
> i2c {
> bcm2048-radio {
> master = <&bcm2048>;
> };
> };
>
> -- Sebastian
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: BCM2048 bluetooth connected over OMAP serial
@ 2014-12-11 22:10 ` Belisko Marek
0 siblings, 0 replies; 20+ messages in thread
From: Belisko Marek @ 2014-12-11 22:10 UTC (permalink / raw)
To: sre@debian.org
Cc: Pavel Machek, Mark Rutland, devicetree@vger.kernel.org,
ijc+devicetree@hellion.org.uk, ivo.g.dimitrov.75@gmail.com,
Pawel Moll, Arnd Bergmann, khilman@kernel.org, tony@atomide.com,
aaro.koskinen@iki.fi, kernel list, robh+dt@kernel.org,
pali.rohar@gmail.com, galak@codeaurora.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Neil Brown send series which implement what was suggested in previous posts:
https://lkml.org/lkml/2014/12/11/454
On Wed, Dec 10, 2014 at 11:50 PM, sre@debian.org <sre@kernel.org> wrote:
> Hi,
>
> On Wed, Dec 10, 2014 at 09:56:22PM +0100, Pavel Machek wrote:
>> On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
>> > On Wed, Dec 10, 2014 at 05:02:42PM +0000, Arnd Bergmann wrote:
>> > > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
>> > > >
>> > > > So, there's bluetooth chip that's connected to the SoC by UART and some
>> > > > GPIOs. What would be right representation in the device tree?
>> > > > Something like this?
>> > > >
>> > > > bluetooth {
>> > > > compatible = "broadcom,bcm2048";
>> > > > uart = <&uart2>;
>> > > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
>> > > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */
>> > > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */
>> > > > chip-type = >;
>> > > > bt-sysclk = <2>;
>> > > > reset-gpio-shared = <0>;
>> > > > };
>> > > >
>> > > > Is there some way to prevent OMAP tty driver from binding to the
>> > > > device and exporting the device to userspace?
>> > >
>> > > I think from the driver perspective, you want this to be a tty line
>> > > discipline rather than a driver that attaches to the physical
>> > > uart.
>> > >
>> > > For the DT representation, I fear we haven't got a precedent. A uart
>> > > phandle sounds reasonable, but there might be other ways to do it
>> > > and we should consider if there are better alternatives. It could
>> > > possibly be a child node of the uart, but that would require other
>> > > infrastructure in the kernel because we don't currently create
>> > > devices for those.
>> >
>> > I think the child node is the way to go; that would match what we do for
>> > I2C and SPI. We might need new infrastructure, but I don't think we
>> > should treat this differently simlpy because we don't have that yet.
>>
>> Well, uart in this case looks more like a GPIO than an I2C (no
>> addressing, just few wires). And we do phandle for GPIOs.
>
> Right and the devices use I2C for full communication and GPIOs as
> helpers. I guess UART counts as full communication and not as helper.
>
> phandle vs child node is not a matter of adressing and btw where is
> the difference between "5th gpio on 1st gpio controller" and "5th
> address on 1st i2c controller"?
>
>> Actually, the chip also has PCM, analog audio, and "pc compatible?"
>> connections, plus some connection to WIFI. So we may need more
>> phandles there....
>
> This is much harder to solve. I think we don't have a DT binding for
> a device, which uses two communication interfaces as the bcm2048
> (uart & i2c). OTOH we may just add a slave device for the fm-radio
> part like this:
>
> uart {
> bcm2048 {
> stuff;
> };
> };
>
> i2c {
> bcm2048-radio {
> master = <&bcm2048>;
> };
> };
>
> -- Sebastian
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply [flat|nested] 20+ messages in thread* BCM2048 bluetooth connected over OMAP serial
@ 2014-12-11 22:10 ` Belisko Marek
0 siblings, 0 replies; 20+ messages in thread
From: Belisko Marek @ 2014-12-11 22:10 UTC (permalink / raw)
To: linux-arm-kernel
Neil Brown send series which implement what was suggested in previous posts:
https://lkml.org/lkml/2014/12/11/454
On Wed, Dec 10, 2014 at 11:50 PM, sre at debian.org <sre@kernel.org> wrote:
> Hi,
>
> On Wed, Dec 10, 2014 at 09:56:22PM +0100, Pavel Machek wrote:
>> On Wed 2014-12-10 18:42:03, Mark Rutland wrote:
>> > On Wed, Dec 10, 2014 at 05:02:42PM +0000, Arnd Bergmann wrote:
>> > > On Wednesday 10 December 2014 17:43:33 Pavel Machek wrote:
>> > > >
>> > > > So, there's bluetooth chip that's connected to the SoC by UART and some
>> > > > GPIOs. What would be right representation in the device tree?
>> > > > Something like this?
>> > > >
>> > > > bluetooth {
>> > > > compatible = "broadcom,bcm2048";
>> > > > uart = <&uart2>;
>> > > > reset-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; /* want 91 */
>> > > > host-wakeup-gpios = <&gpio4 5 GPIO_ACTIVE_HIGH>; /* want 101 */
>> > > > bluetooth-wakeup-gpios = <&gpio2 5 GPIO_ACTIVE_HIGH>; /* want 37 */
>> > > > chip-type = >;
>> > > > bt-sysclk = <2>;
>> > > > reset-gpio-shared = <0>;
>> > > > };
>> > > >
>> > > > Is there some way to prevent OMAP tty driver from binding to the
>> > > > device and exporting the device to userspace?
>> > >
>> > > I think from the driver perspective, you want this to be a tty line
>> > > discipline rather than a driver that attaches to the physical
>> > > uart.
>> > >
>> > > For the DT representation, I fear we haven't got a precedent. A uart
>> > > phandle sounds reasonable, but there might be other ways to do it
>> > > and we should consider if there are better alternatives. It could
>> > > possibly be a child node of the uart, but that would require other
>> > > infrastructure in the kernel because we don't currently create
>> > > devices for those.
>> >
>> > I think the child node is the way to go; that would match what we do for
>> > I2C and SPI. We might need new infrastructure, but I don't think we
>> > should treat this differently simlpy because we don't have that yet.
>>
>> Well, uart in this case looks more like a GPIO than an I2C (no
>> addressing, just few wires). And we do phandle for GPIOs.
>
> Right and the devices use I2C for full communication and GPIOs as
> helpers. I guess UART counts as full communication and not as helper.
>
> phandle vs child node is not a matter of adressing and btw where is
> the difference between "5th gpio on 1st gpio controller" and "5th
> address on 1st i2c controller"?
>
>> Actually, the chip also has PCM, analog audio, and "pc compatible?"
>> connections, plus some connection to WIFI. So we may need more
>> phandles there....
>
> This is much harder to solve. I think we don't have a DT binding for
> a device, which uses two communication interfaces as the bcm2048
> (uart & i2c). OTOH we may just add a slave device for the fm-radio
> part like this:
>
> uart {
> bcm2048 {
> stuff;
> };
> };
>
> i2c {
> bcm2048-radio {
> master = <&bcm2048>;
> };
> };
>
> -- Sebastian
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply [flat|nested] 20+ messages in thread