spi_mpc8xxx: Setting cs_change at the last transfer of a message

As stated in spi.h (at struct spi_transfer) the driver can keep the chip select of the last device active if cs_change is set at the last transfer of a message. The spi_mpc8xxx driver always deactivates the chip select after completing the message regardless of cs_change is set or not. I'd

Re: spi_mpc8xxx.c: chip select polarity problem

by the spi_mpc8xxx driver to set a proper initial value to the associated GPIOs. Signed-off-by: Torsten Fleischer to-fleisc...@t-online.de I like this better. See comments below. [...] Hey Grant, below there is a new version of the patch containing the modifications according to your

Re: spi_mpc8xxx.c: chip select polarity problem

. The following patch adds a function to get the active state of the chip select of a SPI device by looking for the 'spi-cs-high' property in the associated device tree node. This function is used by the spi_mpc8xxx driver to set a proper initial value to the associated GPIOs. Signed-off-by: Torsten

Re: spi_mpc8xxx.c: chip select polarity problem

On Wed, Dec 9, 2009 at 18:46:51 Grant Likely wrote: [...] + ret = of_get_spi_cs_active_state(np, i, astate); + if (ret) { + dev_err(dev, can't get cs active state of device + #%d: %d\n, i, ret); +

Re: spi_mpc8xxx.c: chip select polarity problem

On Thu, Nov 26, 2009 at 13:12:04 Anton Vorontsov wrote: [...] Ah. I understand what you're doing now. Hmmm. This approach concerns me because it relies on firmware or platform code to get CS gpios set up properly before the driver is probed. Yes, that was said at the very beginning of

Re: spi_mpc8xxx.c: chip select polarity problem

occurs. Signed-off-by: Torsten Fleischer to-fleisc...@t-online.de --- diff -u -r -N linux-2.6.31.6_orig//drivers/spi/spi_mpc8xxx.c linux-2.6.31.6/drivers/spi/spi_mpc8xxx.c --- linux-2.6.31.6_orig//drivers/spi/spi_mpc8xxx.c 2009-11-10 01:32:31.0 +0100 +++ linux-2.6.31.6/drivers/spi

Re: spi_mpc8xxx.c: chip select polarity problem

changes. Best Regards Torsten Signed-off-by: Torsten Fleischer to-fleisc...@t-online.de --- diff -u -r -N linux-2.6.31.6_orig//drivers/spi/spi_mpc8xxx.c linux-2.6.31.6/drivers/spi/spi_mpc8xxx.c --- linux-2.6.31.6_orig//drivers/spi/spi_mpc8xxx.c 2009-11-10 01:32:31.0 +0100

Re: spi_mpc8xxx.c: chip select polarity problem

On Wen, Nov 18, 2009 00:28:23 Anton Vorontsov wrote: [...] So it might be better to fix up initial value in the platform code? Oh, we actually cannot, because the driver calls gpio_direction_output(). And since we don't know the mode prior to SPI device's driver

Re: spi_mpc8xxx.c: chip select polarity problem

? Regards Torsten Fleischer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

spi_mpc8xxx.c: chip select polarity problem

of the alow_flags in mpc8xxx_spi_cs_control() or the variable 'pol' in mpc8xxx_spi_chipselect()? Best Regards Torsten Fleischer ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: gianfar.c: Unwanted VLAN tagging on TX frames

On Tuesday 25 August 2009 at 01:32:18, Andy Fleming wrote: Hmmmhow have you tested this? This looks like it has a bad race condition. The TCTRL register applies to all packets, which means if you send a packet with VLAN tags, followed by one without, or visa versa, there's a reasonable

gianfar.c: Unwanted VLAN tagging on TX frames

Hello everyone, I have the Freescale's MPC8313erdb eval board and run the latest stable linux kernel version (linux-2.6.30.5). After creating a VLAN device (e.g. eth0.2) a VLAN tag is also inserted into frames that don't relate to a VLAN device. This is the case for frames that are directly