On 04/09/2016 12:34 PM, Simon Glass wrote:
Hi Stephen,
On 16 March 2016 at 21:46, Stephen Warren swarren@wwwdotorg.org wrote:
The RPi3 typically uses the regular UART for high-speed communication with the Bluetooth device, leaving us the mini UART to use for the serial console. Add support for this UART so we can use it.
Signed-off-by: Stephen Warren swarren@wwwdotorg.org
(This will be a dependency for the RPi 3 patches, so it'd be good if it could make it into mainline pretty quickly if acceptable.)
Reviewed-by: Simon Glass sjg@chromium.org
Not sure if this went in already. But see comment below.
It has, but I can send a fix.
diff --git a/drivers/serial/serial_bcm283x_mu.c b/drivers/serial/serial_bcm283x_mu.c
+static int bcm283x_mu_serial_setbrg(struct udevice *dev, int baudrate) +{
struct bcm283x_mu_priv *priv = dev_get_priv(dev);struct bcm283x_mu_regs *regs = priv->regs;/* FIXME: Get this from plat data later */u32 clock_rate = 250000000;Or device tree?
Well even if DT were used on this platform, the code right here would get the clock rate from platform data. Now, whether the platform data came from a board file or was parsed from DT is another matter.
+static int bcm283x_mu_serial_pending(struct udevice *dev, bool input) +{
struct bcm283x_mu_priv *priv = dev_get_priv(dev);struct bcm283x_mu_regs *regs = priv->regs;unsigned int lsr = readl(®s->lsr);if (input) {WATCHDOG_RESET();return lsr & BCM283X_MU_LSR_RX_READY;} else {return !(lsr & BCM283X_MU_LSR_TX_IDLE);These look like flags - be care to return 1 if there is an unknown number of characters, rather than (e.g. 4). The latter might cause the uclass to expect 4 characters to be present.
Suggest putting ? 1 : 0 or ? 0 : 1 on the end.
Luckily BCM283X_MU_LSR_RX_READY is BIT(0) so there's no practical issue. A !! would make this more obvious at this point in the code though. Do you think that warrants a patch? The ! on the second return also ensure the correct return value.