Messages in this thread | | | From | Mike Frysinger <> | Date | Fri, 25 Sep 2009 16:48:27 -0400 | Subject | Re: [PATCH v2] fbdev: bfin-lq035q1-fb: new Blackfin Landscape LCD EZ-Extender driver |
| |
On Fri, Sep 25, 2009 at 16:24, Mike Frysinger wrote: > On Thu, Sep 24, 2009 at 19:32, Andrew Morton wrote: >> On Thu, 17 Sep 2009 17:37:06 -0400 Mike Frysinger wrote: >>> +static int lq035q1_control(unsigned char reg, unsigned short value) >>> +{ >>> + int ret; >>> + u8 regs[3] = {LQ035_INDEX, 0, 0}; >>> + u8 dat[3] = {LQ035_DATA, 0, 0}; >>> + >>> + if (spi_control.spidev) { >>> + regs[2] = reg; >>> + dat[1] = value >> 8; >>> + dat[2] = value & 0xFF; >>> + >>> + ret = spi_write(spi_control.spidev, regs, ARRAY_SIZE(regs)); >>> + ret |= spi_write(spi_control.spidev, dat, ARRAY_SIZE(dat)); >>> + } else >>> + return -ENODEV; >>> + >>> + return ret; >>> +} >> >> I am suspecting that this function (and the similar ones below) rely >> upon state within the hardware and will hence misbehave if two >> instances are run concurrently. >> >> Is that correct> If so, is there locking to prevent this from occurring? > > if by "instances" you mean "users" as in "multiple programs > reading/writing the framebuffer concurrently", then probably. rather > than handle the locking ourselves, it can be pushed to the SPI bus by > having the regs/dat be transfers in a single message.
hmm there shouldnt be any locking problems here actually. the spi access is only to initialize/shutdown, and there is a dedicated CS for each device. so i dont think anything here really needs changing (other than to allocate the spi_control global variable dynamically in the probe). -mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |