Re: [PATCH v5 0/5] Add memory mapped read support for ti-qspi

On Tue, Jan 05, 2016 at 10:50:42AM +0530, Vignesh R wrote: > Hi Brian, > > On 12/11/2015 09:39 AM, Vignesh R wrote: > > Changes since v4: > > Use syscon to access system control module register in ti-qspi driver. > > > > Gentle ping... > Are you ok with MTD side changes of this patch series?

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Thu, Dec 31, 2015 at 10:59:06PM +0100, Paul Kocialkowski wrote: > I understand, thanks for pointing this out. Well, for my use case, there > is no use in disabling the chip at any point as it powers the external > mmc. Presumably someone might decide not to use the MMC in some case (perhaps

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Wed, Dec 30, 2015 at 07:37:19PM +0100, Paul Kocialkowski wrote: > Le mercredi 30 décembre 2015 à 16:33 +0000, Mark Brown a écrit : > > On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote: > > > In my opinion, it would be more elegant to adapt the core regulat

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote: > In my opinion, it would be more elegant to adapt the core regulator > framework to first enable the GPIO and then call the regulator enable > ops callback instead of handling the GPIO in the driver. Why would we want to

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Thu, Dec 24, 2015 at 07:12:53PM +0100, Paul Kocialkowski wrote: > Le mercredi 23 décembre 2015 à 11:56 +0000, Mark Brown a écrit : > > This isn't really adding support for the enable GPIO as the changelog > > suggests, it's requesting but not managing the GPIO. Since there is &

Re: [PATCH 3/6] regulator: lp872x: Remove warning about invalid DVS GPIO

On Wed, Dec 23, 2015 at 11:58:36AM +0100, Paul Kocialkowski wrote: > Some devices don't hook the DVS pin to a GPIO but to ground or VCC. > In those cases, it is not a problem to have no DVS GPIO. I would expect the driver at least needs to know how the pins or strapped, or otherwise have

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Wed, Dec 23, 2015 at 11:58:37AM +0100, Paul Kocialkowski wrote: > + gpio = lp->pdata->enable_gpio; > + if (!gpio_is_valid(gpio)) > + return 0; > + > + /* Always set enable GPIO high. */ > + ret = devm_gpio_request_one(lp->dev, gpio, GPIOF_OUT_INIT_HIGH, "LP872X >

Re: [PATCH 3/6] regulator: lp872x: Remove warning about invalid DVS GPIO

On Wed, Dec 23, 2015 at 12:50:20PM +0100, Paul Kocialkowski wrote: > Le mercredi 23 décembre 2015 à 11:41 +0000, Mark Brown a écrit : > > I would expect the driver at least needs to know how the pins or > > strapped, or otherwise have configuration for ignoring the input

Re: [PATCH v4 1/5] spi: introduce accelerated read support for spi flash devices

On Mon, Nov 30, 2015 at 10:45:11AM +0530, Vignesh R wrote: > In addition to providing direct access to SPI bus, some spi controller > hardwares (like ti-qspi) provide special port (like memory mapped port) > that are optimized to improve SPI flash read performance. I'm reasonably OK with this

Re: [PATCH v2 1/5] spi: introduce mmap read support for spi flash devices

On Thu, Nov 05, 2015 at 05:59:36PM +0530, Vignesh R wrote: > On 11/04/2015 08:09 PM, Mark Brown wrote: > > It's a bit worrying that this doesn't sync with the message queue except > > via the mutex: this means that we might be out of order with respect to > > any a

Re: [PATCH v2 2/5] spi: spi-ti-qspi: add mmap mode read support

On Tue, Nov 03, 2015 at 03:36:11PM +0530, Vignesh R wrote: > + ti_qspi_enable_memory_map(spi); > + ti_qspi_setup_mmap_read(spi, read_opcode, addr_width, > + dummy_bytes); > + memcpy_fromio(buf, qspi->mmap_base + from, len); > + *retlen = len; > +

Re: [PATCH v2 1/5] spi: introduce mmap read support for spi flash devices

On Tue, Nov 03, 2015 at 03:36:10PM +0530, Vignesh R wrote: > + } > + mutex_lock(>mmap_lock_mutex); > + ret = master->spi_mtd_mmap_read(spi, from, len, retlen, buf, > + read_opcode, addr_width, > + dummy_bytes); >

Re: [PATCH] regulator: tps65217: remove tps65217.dtsi file

On Mon, Oct 26, 2015 at 10:13:55AM +0100, Heiko Schocher wrote: > remove tps65217.dtsi and adapt all boards, which > used it. Acked-by: Mark Brown <broo...@kernel.org> but really this is a DTS change so I'd expect it to go via arm-soc rather than me. signature.asc Description: PGP signature

Re: [PATCH RFC] ASoC: simple-card: Update clocks binding for simple-card DAI subnodes

On Mon, Sep 28, 2015 at 09:49:35PM +0300, Jyri Sarha wrote: > On 09/19/15 21:42, Mark Brown wrote: > >What's the use case again? Can we address this by converting the > >relevant drivers to the clock API (or improving their clock API > >support)? > Sorry, I forg

Re: [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On Mon, Sep 21, 2015 at 04:41:20PM +0300, Jyri Sarha wrote: > On 09/21/15 12:31, Russell King - ARM Linux wrote: > >The device may accept 32 bit I2S, but it would have to be truncated to > >24 bit before transmitting it to the sink. This should be mentioned > >somewhere. > There is ".sig_bits =

Re: [PATCH RFC v4 2/8] ALSA: pcm: add IEC958 channel status helper for hw_params

On Fri, Sep 18, 2015 at 02:06:39PM +0300, Jyri Sarha wrote: > Add IEC958 channel status helper that gets the audio properties from > snd_pcm_hw_params instead of snd_pcm_runtime. This is needed to > produce the channel status bits already in audio stream configuration > phase. > > Signed-off-by:

Re: [PATCH RFC] ASoC: simple-card: Update clocks binding for simple-card DAI subnodes

On Fri, Sep 11, 2015 at 04:18:02PM +0300, Jyri Sarha wrote: > The updated binding provides a way to set clock-ID and direction > parameters for DAI drivers set_sysclk() call back. > I proposed something similar about a year ago, but Mark rejected that > at the time. This RFC is to start that

Re: [PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On Fri, Sep 18, 2015 at 02:06:40PM +0300, Jyri Sarha wrote: > +#define SPDIF_FORMATS(SNDRV_PCM_FMTBIT_S16_LE | > SNDRV_PCM_FMTBIT_S16_BE |\ > + SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_S20_3BE |\ > + SNDRV_PCM_FMTBIT_S24_3LE |

Re: [PATCH] ASoC: soc-core: Fix sparse warning in be32_to_cpup() call

On Thu, Sep 17, 2015 at 11:02:57AM +0300, Jyri Sarha wrote: > val /= sizeof(u32); > for (i = 0; i < val; i++) > - if (be32_to_cpup(_slot_mask[i])) > + if (be32_to_cpup((__be32 *)_slot_mask[i])) > *mask |= (1 << i); > There was no

Re: [PATCH 1/5] spi: introduce mmap read support for spi flash devices

On Wed, Sep 16, 2015 at 03:38:09PM +0530, Vignesh R wrote: > But, I didn't get how to integrate with existing message queue. Memory > mapped read by-passes message queue of SPI core. Could you please > explain a bit more on integrating with message queue? Did you mean > locking the existing

Re: [PATCH 1/5] spi: introduce mmap read support for spi flash devices

On Wed, Sep 16, 2015 at 06:16:55PM +0530, Jagan Teki wrote: > On 15 September 2015 at 00:05, Mark Brown <broo...@kernel.org> wrote: > > There seem to be a reasonable number of SPI controllers out there which > > have as an extension the ability to do memory mapped reads

Re: [PATCH RFC 4/5] ASoC: davinci-mcasp: Get rid of bclk_lrclk_ratio in private data

On Thu, Sep 10, 2015 at 10:16:30AM +0300, Jyri Sarha wrote: > On 09/09/15 21:27, Jyri Sarha wrote: > >+dev_warn(mcasp->dev, > >+ "%s(): BCLK/LRCLK %d is not divisible by %d > >tdm slots", > >+ div, mcasp->tdm_slots); >

Re: [PATCH 1/5] spi: introduce mmap read support for spi flash devices

On Fri, Sep 04, 2015 at 04:55:33PM +0530, Jagan Teki wrote: > On 4 September 2015 at 13:59, Vignesh R wrote: > > + * @spi_mtd_mmap_read: some spi-controller hardwares provide memory > > + * mapped interface to communicate with mtd flashes. > > + *

Re: [PATCH 2/5] spi: spi-ti-qspi: add mmap mode read support

On Fri, Sep 04, 2015 at 01:59:59PM +0530, Vignesh R wrote: > +static int ti_qspi_spi_mtd_mmap_read(struct spi_device *spi, > + loff_t from, size_t len, > + size_t *retlen, u_char *buf, > + u8

Re: [PATCH 3/5] mtd: devices: m25p80: add support for mmap read request

On Fri, Sep 04, 2015 at 02:00:00PM +0530, Vignesh R wrote: > + if (spi->master->spi_mtd_mmap_read) { > + return spi->master->spi_mtd_mmap_read(spi, from, len, > +retlen, buf, > +

Re: [PATCH 1/5] spi: introduce mmap read support for spi flash devices

On Fri, Sep 04, 2015 at 01:59:58PM +0530, Vignesh R wrote: > In addition to providing direct access to SPI bus, some spi controller > hardwares (like ti-qspi) provide special memory mapped port > to accesses SPI flash devices in order to increase read performance. > This means the controller can

Re: [PATCH v3 1/2] regulator: pbias: program pbias register offset in pbias driver

On Fri, Sep 04, 2015 at 05:30:24PM +0530, Kishon Vijay Abraham I wrote: > Add separate compatible strings for every platform and populate the > pbias register offset in the driver data. > This helps avoid depending on the dt for pbias register offset. If there are any changes from the already

Re: [PATCH 1/6] regulator: pbias: program pbias register offset in pbias driver

On Wed, Sep 02, 2015 at 04:17:28PM +0530, Kishon Vijay Abraham I wrote: > Add separate compatible strings for every platform and populate the > pbias register offset in the driver data. > This helps avoid depending on the dt for pbias register offset. Can you respin with Tony's comment please and

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

On Tue, Sep 01, 2015 at 11:56:06AM -0700, Tony Lindgren wrote: > * Mark Brown <broo...@kernel.org> [150901 11:40]: > > That'd work. The other thing I was thinking we could do is to get > > syscon to treat any excessively large address that gets passed in that > > loo

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

On Tue, Sep 01, 2015 at 07:17:21AM -0700, Tony Lindgren wrote: > Why don't you just make reg unused for pbias_regulator since > we already use regmap for this driver? > Then in the pbias driver just define the register offset from > the syscon base? You may need to set it based on the compatible

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

On Mon, Aug 31, 2015 at 04:14:07PM +0530, Kishon Vijay Abraham I wrote: > On Tuesday 25 August 2015 07:20 PM, Mark Brown wrote: > > On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote: > >> On 08/19/2015 09:11 PM, Mark Brown wrote: > >>> So substra

Re: [PATCH] spi: omap2-mcspi: add runtime PM to set_cs()

On Sun, Aug 30, 2015 at 11:44:45AM -0500, Michael Welling wrote: > The patch is currently sitting in linux-next. > Not sure why it wasn't merged with 4.2.0-rc8. You didn't indicate that it was a bug fix for Linus rather than a fix for recent development :( signature.asc Description: Digital

Re: [PATCH] spi: omap2-mcspi: add runtime PM to set_cs()

On Mon, Aug 31, 2015 at 08:46:46AM -0500, Michael Welling wrote: > On Mon, Aug 31, 2015 at 09:53:55AM +0100, Mark Brown wrote: > > On Sun, Aug 30, 2015 at 11:44:45AM -0500, Michael Welling wrote: > > > The patch is currently sitting in linux-next. > > > Not sure why

Re: [PATCH 0/2] OMAPDSS: Couple of HDMI audio fixes

On Wed, Aug 26, 2015 at 04:11:38PM +0300, Jyri Sarha wrote: The two fixes are totally independent and the video and audio side patches applied separately trough their own trees. In general if patches aren't related to each other either through code overlap or through content it's better to

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

On Tue, Aug 25, 2015 at 01:03:04PM +0300, Grygorii Strashko wrote: On 08/19/2015 09:11 PM, Mark Brown wrote: So substract this address from the start of the resource to get the offset? Or provide a wrapper function in the resource code which does that. I'd be very appreciated if you

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

On Thu, Aug 20, 2015 at 11:21:06AM +0530, Kishon Vijay Abraham I wrote: On Wednesday 19 August 2015 11:41 PM, Mark Brown wrote: On Tue, Aug 18, 2015 at 11:23:54AM +0530, Kishon Vijay Abraham I wrote: Please fix your mail client to word wrap within paragraphs. platform_get_resource can

Re: [PATCH] spi: ti-qspi: use 128 bit transfer mode for writing to flash

On Thu, Aug 20, 2015 at 04:00:59PM +0530, Vignesh R wrote: - writeb(*txbuf, qspi-base + QSPI_SPI_DATA_REG); + if (count = QSPI_WLEN_MAX_BYTES) { + u32 *txp = (u32 *)txbuf; + + data =

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

On Tue, Aug 18, 2015 at 11:23:54AM +0530, Kishon Vijay Abraham I wrote: On Friday 14 August 2015 11:30 PM, Mark Brown wrote: On Mon, Jul 27, 2015 at 04:54:09PM +0530, Kishon Vijay Abraham I wrote: is moved as a child node of syscon, vsel_reg and enable_reg has the absolute address because

Re: [PATCH RFC v3 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On Mon, Aug 17, 2015 at 10:07:55AM +0300, Jyri Sarha wrote: On 08/14/15 19:18, Mark Brown wrote: On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote: + /* Called when ASoC starts an audio stream setup. The call +* provides an audio abort callback for stoping an ongoing

Re: [PATCH RFC v3 2/7] ASoC: hdmi: Remove obsolete dummy HDMI codec

On Mon, Aug 17, 2015 at 10:00:07AM +0300, Jyri Sarha wrote: On 08/14/15 19:10, Mark Brown wrote: Don't you mean omap-hdmi-audio, that is implemented in sound/soc/omap/omap-hdmi-audio.c ? That driver is bit different. It implements ASoC card and uses generic dummy codec. The hdmi-audio-codec

Re: [PATCH RFC v2 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On Tue, May 26, 2015 at 09:59:07PM +0300, Jyri Sarha wrote: + + mutex_lock(hcp-current_stream_lock); + if (hcp-current_stream hcp-current_stream-runtime + snd_pcm_running(hcp-current_stream)) { + dev_info(dev, HDMI audio playback aborted\n); Does this really

Re: [PATCH RFC v3 2/7] ASoC: hdmi: Remove obsolete dummy HDMI codec

On Fri, Aug 14, 2015 at 12:30:40PM +0300, Jyri Sarha wrote: The hdmi stub codec has not been used since refactoring of OMAP HDMI audio support. grep tells me that the OMAP HDMI4 and HDMI5 drivers are still registering this device in -next... signature.asc Description: Digital signature

Re: [PATCH RFC v3 3/7] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

On Fri, Aug 14, 2015 at 12:30:41PM +0300, Jyri Sarha wrote: +struct hdmi_codec_ops { + /* For runtime clock configuration from ASoC machine driver. + * A direct forward from set_sysclk in struct snd_soc_dai_ops. + * Optional */ + int (*set_clk)(struct device *dev, int

Re: [PATCH 1/2] regulator: pbias: use untranslated address to program pbias regulator

On Mon, Jul 27, 2015 at 04:54:09PM +0530, Kishon Vijay Abraham I wrote: vsel_reg and enable_reg of the pbias regulator descriptor should actually have the offset from syscon. However after the pbias device tree node I'm having a hard time understanding this statement, sorry. What makes you

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Thu, Aug 06, 2015 at 11:22:25AM +0100, Russell King - ARM Linux wrote: If that's the case, then maybe you should consider whether using the SPI bus infrastructure is really the best way forward. Would it make more sense instead to adopt a different software structure, something more

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Thu, Aug 06, 2015 at 12:01:37PM +0200, Michal Suchanek wrote: However, I am familiar m25p80.c and as I understand it the controller is basically supposed to implement m25p80.c in hardware when this flag is set. But what in concrete terms is that supposed to mean? It's currently just an

Re: next-20150806 build: 2 failures 52 warnings (next-20150806)

On Thu, Aug 06, 2015 at 12:00:47PM +0100, Build bot for Mark Brown wrote: Today's linux-next fails to build an ARM allmodconfig with: ../drivers/iommu/omap-iommu-debug.c:138:2: error: void value not ignored as it ought to be caused by a combination of 1ba2f20ac (fs/seq_file: convert int

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Thu, Aug 06, 2015 at 02:51:29PM +0100, Russell King - ARM Linux wrote: The M25P80 driver just appends additional bytes to the message to achieve this: struct m25p *flash = nor-priv; unsigned int dummy = nor-read_dummy; /* convert the dummy cycles to the number

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Thu, Aug 06, 2015 at 05:55:23PM +0530, Vignesh R wrote: 1.Write to flash config register via config port to switch to QUAD MODE (or any mode that flash supports). 2. Populate QSPI_SPI_SETUP_REGx with flash read command, number of address bytes to use and dummy bytes required. These things

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Wed, Aug 05, 2015 at 02:56:09PM +0200, Michal Suchanek wrote: On 5 August 2015 at 14:44, Mark Brown broo...@kernel.org wrote: On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote: I don't think sending 03 or other random byte as the first byte of a SPI transfer can be used

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Thu, Aug 06, 2015 at 01:42:32PM +0200, Michal Suchanek wrote: On 6 August 2015 at 13:23, Mark Brown broo...@kernel.org wrote: Sure, but at the end of the day it's just emitting standard SPI messages which don't know anything about flash. If those messages are a sensible interface here

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Tue, Aug 04, 2015 at 11:29:52PM +0530, R, Vignesh wrote: On 8/4/2015 9:21 PM, Mark Brown wrote: On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote: I still can't tell from the above what this interface is supposed to do. It sounds like the use of memory mapped mode is supposed

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Wed, Aug 05, 2015 at 02:40:01PM +0200, Michal Suchanek wrote: On 5 August 2015 at 13:50, Mark Brown broo...@kernel.org wrote: As far as I can tell you want to set a per spi_message flag saying that the message is a flash read command? If that's what this is trying to do then why do you

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Mon, Aug 03, 2015 at 10:27:19AM +0530, Vignesh R wrote: @use_mmap_mode: Some SPI controller chips are optimized for interacting with serial flash memories. These chips have memory mapped interface, through which entire serial flash memory slave can be read/written as if though they are

Re: [RFC PATCH 4/5] ARM: dts: DRA7: Add memory map region entries for qspi

On Mon, Aug 03, 2015 at 10:32:09AM +0530, Vignesh R wrote: On 07/31/2015 11:49 PM, Mark Brown wrote: - reg = 0x4790 0x100; + reg = 0x4790 0x100, +0x3000 0x3ff; + reg-names = qspi_base, qspi_mmap

Re: [RFC PATCH 1/5] spi: introduce flag for memory mapped read

On Tue, Jul 28, 2015 at 02:11:12PM +0530, Vignesh R wrote: Introduce use_mmap_read field in spi_message struct. This can be set by mtd devices (m25p80) to indicate to spi-master (ti-qspi) to perform memory mapped read. This helps to distinguish whether the spi-message is from mtd layer(hence

Re: [RFC PATCH 4/5] ARM: dts: DRA7: Add memory map region entries for qspi

On Tue, Jul 28, 2015 at 02:11:15PM +0530, Vignesh R wrote: Add qspi memory mapped region entries for DRA7xx based SoCs. Signed-off-by: Vignesh R vigne...@ti.com qspi: qspi@4790 { compatible = ti,am4372-qspi; - reg = 0x4790

Re: [PATCH] spi: omap2-mcspi: add runtime PM to set_cs()

On Wed, Jul 22, 2015 at 08:46:09PM +0200, Sebastian Reichel wrote: Since commit ddcad7e9068eb omap2_mcspi_set_cs() is called without runtime power management requested. Thus the below kernel oops may be generated if a device is accessed after the runtime power management timeout. This patch

Re: [PATCH 1/2] V4 regmap: Use reg_sequence for multi_reg_write / register_patch

On Tue, Jul 14, 2015 at 03:45:51PM +0100, Nariman Poushin wrote: Please submit patches in the format covered in SubmittingPatches, version information goes inside the []. Add support for writing sequences of registers / patches with specified delays (in microseconds). Logically separates the

Re: [alsa-devel] [PATCH 1/2] V4 regmap: Use reg_sequence for multi_reg_write / register_patch

On Thu, Jul 16, 2015 at 04:45:25PM +0100, Nariman Poushin wrote: I will resend with a cover letter explaining the change from the previous patch set if that is the right thing to do. No, that's fine. If you want to fix something like that just reply to the cover letter with the extra

Re: [PATCH 2/2 V5] regmap: Apply optional delay in multi_reg_write/register_patch

On Thu, Jul 16, 2015 at 04:36:22PM +0100, Nariman Poushin wrote: + + if (regs[i].delay_us) + udelay(regs[i].delay_us); This is a bit funky. While Takashi is correct that we could be running in a spinlock equally this will mean that we could end

Re: next-20150629 build: 1 failures 74 warnings (next-20150629)

On Mon, Jun 29, 2015 at 11:36:17AM +0100, Build bot for Mark Brown wrote: Today's -next fails to build an ARM allmodconfig due to: ../drivers/watchdog/omap_wdt.c:288:18: error: 'omap_wdt' undeclared (first use in this function) which is introduced by watchdog: omap_wdt: early_enable module

Re: [PATCH v3] ASoC: davinci-mcasp: Choose PCM driver based on configured DMA controller

On Tue, Jun 02, 2015 at 11:09:34PM +0300, Jyri Sarha wrote: Find the configured DMA controller by asking for a DMA channel in the probe phase and releasing it right after. The controller device can be found via the dma_chan struct and the controller is recognized from the compatible property

Re: next-20150604 build: 2 failures 37 warnings (next-20150604)

On Fri, Jun 05, 2015 at 07:49:00PM +0900, Greg Kroah-Hartman wrote: On Thu, Jun 04, 2015 at 10:20:26AM -0700, Tony Lindgren wrote: Greg, there's now commit 9809889c708e in tty-linus and commit 9e91597f2423 in tty-next. Yes, I can't go back and remove the one in tty-next, I'm guessing when

Re: next-20150604 build: 2 failures 37 warnings (next-20150604)

On Thu, Jun 04, 2015 at 10:20:26AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150604 10:11]: Sounds like I'm using an old commit in one of my pending branches, will check immediately. Greg, there's now commit 9809889c708e in tty-linus and commit 9e91597f2423 in

Re: next-20150604 build: 2 failures 37 warnings (next-20150604)

On Thu, Jun 04, 2015 at 05:47:05PM +0100, Build bot for Mark Brown wrote: arm-allmodconfig ../drivers/tty/serial/8250/8250_omap.c:586:20: error: redefinition of 'omap8250_irq' Current -next fails to build an ARM allmodconfig (and possibly other things) due to 9e91597f24234

Re: [PATCH RFC v2 2/7] ASoC: hdmi: Remove obsolete dummy HDMI codec

On Tue, May 26, 2015 at 09:59:06PM +0300, Jyri Sarha wrote: -#ifdef CONFIG_OF -static const struct of_device_id hdmi_audio_codec_ids[] = { - { .compatible = linux,hdmi-audio, }, - { } -}; -MODULE_DEVICE_TABLE(of, hdmi_audio_codec_ids); -#endif There is actually a binding document,

Re: [PATCH RFC v2 1/7] ASoC: core: If component doesn't have of_node use parent's node instead

On Tue, May 26, 2015 at 09:59:05PM +0300, Jyri Sarha wrote: If an ASoC component device does not have a device tree node, use its parent's node instead, when looking for a matching DAI based on a device tree reference. Applied, thanks. signature.asc Description: Digital signature

Re: [PATCH] ASoC: davinci-mcasp: Choose PCM driver based on configured DMA controller

On Tue, Jun 02, 2015 at 01:31:28PM +0300, Peter Ujfalusi wrote: On 06/02/2015 11:58 AM, Jyri Sarha wrote: +enum { + MCASP_EDMA = 1, Why start from 1? It's a fairly common style to ensure that zero initialised structures don't have a default value. Don't know if that's the intent here

Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels

On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. Acked-by: Mark

Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels

On Wed, May 27, 2015 at 02:15:12PM +0300, Peter Ujfalusi wrote: I have put the maintainers of the relevant subsystems as CC in the commit message and sent the series to all of the mailing lists. This series was touching 7 subsystems and I thought not spamming every maintainer with all the

Re: [PATCH 13/13] ASoC: omap-pcm: Switch to use dma_request_slave_channel_compat_reason()

On Tue, May 26, 2015 at 04:26:08PM +0300, Peter Ujfalusi wrote: dmaengine provides a wrapper function to handle DT and non DT boots when requesting DMA channel. Use that instead of checking for of_node in the platform driver. Acked-by: Mark Brown broo...@kernel.org signature.asc Description

Re: [PATCH 11/13] spi: omap2-mcspi: Support for deferred probing when requesting DMA channels

On Tue, May 26, 2015 at 04:26:06PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. Only fall back to pio mode if the error code returned is not -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER. I've got two

Re: [PATCH 0/4] spi: omap2-mcspi: Fixes for recent updates

On Sat, May 23, 2015 at 09:13:41PM -0500, Michael Welling wrote: The recent update of the OMAP2 McSPI driver left some unresolved issues. These patches should take care them and again allow for GPIO chip selects and native chip selects. Applied all, thanks. signature.asc Description: Digital

Re: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs

On Thu, May 21, 2015 at 06:48:33PM -0500, Michael Welling wrote: So after reverting this patch I found there is a issue in that it is difficult to determine when a transfer is complete to properly drive the chipselect from within the transfer_one function. Is unprepare_message() a suitable

Re: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs

On Thu, May 21, 2015 at 04:04:11PM -0500, Michael Welling wrote: Do you want to revert the patch and apply a new one or should I provide a patch that reverts the changes and fixes it all in one? Can you please send me separate revert and re-add patches, that's probably going to be easier to

Re: [PATCH] spi: omap2-mcspi: Fix native cs with new set_cs

On Wed, May 20, 2015 at 09:07:09PM -0500, Michael Welling wrote: My guess is that the set_cs needs to be called even when toggling as GPIO. How should I handle this? It shouldn't be part of a set_cs() operation but rather part of the main transfer operation. signature.asc Description:

Re: [PATCH] ASoC: omap: fix up SND_OMAP_SOC_OMAP_ABE_TWL6040 dependency, again

On Tue, May 19, 2015 at 02:47:32PM +0200, Arnd Bergmann wrote: I tried to fix this before and submitted a working patch, but after some discussion we came up with what seemed to be a nicer solution, resulting in commit 3d4cf65e2d (ASoC: omap: fix up SND_OMAP_SOC_OMAP_ABE_TWL6040 dependency).

Re: [PATCH] ASoC: rx51: use flags argument of devm_gpiod_get to set direction

On Tue, May 19, 2015 at 09:48:08AM +0200, Uwe Kleine-König wrote: Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions) which appeared in v3.17-rc1, the gpiod_get* functions take an additional parameter that allows to specify direction and initial value for output. Applied,

Re: [PATCH] ASoC: rx51: use flags argument of devm_gpiod_get to set direction

On Tue, May 19, 2015 at 11:16:50AM +0300, Jarkko Nikula wrote: I don't think Fixes tag is justified. Otherwise than that Yes, I don't see any bug fixing here - am I missing something? signature.asc Description: Digital signature

Re: [PATCH 5/5] ASoC: omap-hdmi-audio: Fix invalid combination of DM_INH and CA

On Wed, Apr 22, 2015 at 04:23:01PM +0300, Jyri Sarha wrote: From: Misael Lopez Cruz misael.lo...@ti.com DM_INH = 1 (stereo downmix prohibited) and CA = 0x00 (Channel Allocation: FR, FL) is an invalid combination according to the HDMI Compliance Test 7.31 Audio InfoFrame. Acked-by: Mark

Re: [PATCH 4/5] ASoC: omap-hdmi-audio: Force channel allocation only for OMAP4

On Wed, Apr 22, 2015 at 04:23:00PM +0300, Jyri Sarha wrote: From: Misael Lopez Cruz misael.lo...@ti.com There is a constraint in the OMAP4 HDMI IP that requires to use the 8-channel code when transmitting more than two channels. Acked-by: Mark Brown broo...@kernel.org signature.asc

Re: LDP: next-20150402: twl4030 regression?

On Mon, Apr 06, 2015 at 08:21:49AM -0500, Nishanth Menon wrote: https://github.com/nmenon/kernel-test-logs/blob/next-20150401/omap2plus_defconfig/ldp.txt looks clean, but https://github.com/nmenon/kernel-test-logs/blob/next-20150402/omap2plus_defconfig/ldp.txt#L488 seems to have picked up a

Re: LDP: next-20150402: twl4030 regression?

On Mon, Apr 06, 2015 at 02:58:29PM +0100, Russell King - ARM Linux wrote: On Mon, Apr 06, 2015 at 08:53:36AM -0500, Nishanth Menon wrote: at least a description of the problem you're seeing and some attempt at Test was a simple boot test. There seems to be a lockdep reported at the very

Re: [PATCH] ASoC: davinci-mcasp: Index ruledata in drvdata with substream-stream

On Fri, Mar 27, 2015 at 11:47:51AM +0200, Jyri Sarha wrote: The serializer direction definitions runs from 1 to 2, which does not suite the purpose. The substream-stream is perfect for the purpose and should have been used from the beginning. Applied, thanks. signature.asc Description:

Re: [PATCH] ASoC: davinci-evm: drop un-necessary remove function

On Thu, Mar 26, 2015 at 03:38:25PM +0200, Jyri Sarha wrote: From: Manish Badarkhe manis...@ti.com As davinci card gets registered using 'devm_' api there is no need to unregister the card in 'remove' function. Hence drop the 'remove' function. Not only that but the current remove function

Re: [PATCH v3] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used

On Fri, Mar 20, 2015 at 01:31:08PM +0200, Jyri Sarha wrote: Set rule constraints to allow only combinations of sample-rate, sample-format, and channels counts that can be played/captured with reasonable sample-rate accuracy. Applied, thanks. signature.asc Description: Digital signature

Re: Patch to parameterize DMA_MIN_BYTES for omap2-mcspi

On Fri, Mar 20, 2015 at 03:10:04PM +0200, Peter Ujfalusi wrote: On 03/19/2015 08:51 PM, Mark Brown wrote: You probably need both - there's often a hard limit where the FIFO size in the hardware becomes a limit for DMA as well as a soft limit on top of that for performance reasons

Re: Patches to bind the SGTL5000 chip to AM33XX McASP

On Thu, Mar 19, 2015 at 01:48:08PM -0400, Greg Knight wrote: Is there a straightforward way we could enable the clock on-demand - when we're communicating with the codec/mixer or actually using the audio subsystem - while keeping it disabled when not in use? We don't expect to be using the

Re: [alsa-devel] Patches to bind the SGTL5000 chip to AM33XX McASP

On Thu, Mar 19, 2015 at 08:06:15PM +0200, Nikolay Dimitrov wrote: Correct. And this is a big issue. As far as I know, the kernel drivers control separately the clock domains, and separately i2c devices, so the basic expectation on the kernel side is that there's no connection between these 2.

Re: Patch to parameterize DMA_MIN_BYTES for omap2-mcspi

On Thu, Mar 19, 2015 at 01:05:01AM -0400, Greg Knight wrote: What is the process for getting this upstreamed? Please submit the patch following the process in Documentation/SubmittingPatches. signature.asc Description: Digital signature

Re: [PATCH v2] ASoC: davinci-mcasp: Set rule constraints if implicit BCLK divider is used

On Thu, Mar 19, 2015 at 10:51:09AM +0200, Jyri Sarha wrote: Set rule constraints to allow only combinations of sample-rate, sample-bits, and channels that can be played/captured with reasonable sample-rate accuracy. This doesn't apply against current code, please check and resend.

Re: Patches to bind the SGTL5000 chip to AM33XX McASP

On Thu, Mar 19, 2015 at 01:07:39AM -0400, Greg Knight wrote: These patches are based off of 3.14.31-ti-r49. What is the process for getting these merged? Please submit patches using the process in SubmittingPatches, you need to work against current development versions of the kernel rather

Re: Patch to parameterize DMA_MIN_BYTES for omap2-mcspi

On Thu, Mar 19, 2015 at 09:16:31AM -0400, Greg Knight wrote: Will refer to that documentation and update the SPI docs before resubmitting. Please don't top post on kernel lists, reply in line (deleting any unneeded context) so people have context for what you are talking about. This makes

Re: [PATCH 02/35 linux-next] regulator: constify of_device_id array

On Tue, Mar 17, 2015 at 06:26:17PM +0100, Fabian Frederick wrote: On 17 March 2015 at 18:19 Mark Brown broo...@kernel.org wrote: Well, another thing to do if there's no dependencies is to just send each patch separately - there's no real relationship between the patches.  This also avoids

Re: Patch to parameterize DMA_MIN_BYTES for omap2-mcspi

On Thu, Mar 19, 2015 at 01:28:00PM -0400, Greg Knight wrote: Changing DMA_MIN_BYTES to, say, dma_min_time_ms sounds reasonable to me. I don't know how to compute it completely accurately as some SPI You probably need both - there's often a hard limit where the FIFO size in the hardware becomes

Re: [PATCH 02/35 linux-next] regulator: constify of_device_id array

On Tue, Mar 17, 2015 at 06:10:12PM +0100, Fabian Frederick wrote: Thanks Mark, I used a --cc-cmd script by Joe Perches with git send-email which uses --nom for cover-letter. This limits recipients to mailing lists: 37 instead of 123 in this case. I guess it's better to reduce the noise :)

Re: [PATCH 02/35 linux-next] regulator: constify of_device_id array

On Mon, Mar 16, 2015 at 08:17:08PM +0100, Fabian Frederick wrote: of_device_id is always used as const. (See driver.of_match_table and open firmware functions) Applied, thanks. Please remember to always include people in the cover letter for patch serieses so they know what's going on with

Re: [PATCH 0/2] regulator: TPS659038: Fixes for REGEN2 and REGEN3

On Tue, Mar 17, 2015 at 03:56:03PM +0530, Keerthy wrote: The series fixes couple of issues in the driver w.r.t TPS659038 PMICs. 1) Correcting the REGEN2_CTRL address. 2) REGEN3 is not present hence adding a check not to register for TPS659038. Applied both, thanks. regulator: palmas:

Re: [PATCH] regulator: tps65910: Add missing #include linux/of.h

On Sun, Mar 15, 2015 at 02:03:50PM +0100, Geert Uytterhoeven wrote: drivers/regulator/tps65910-regulator.c: In function ‘tps65910_parse_dt_reg_data’: drivers/regulator/tps65910-regulator.c:1018: error: implicit declaration of function ‘of_get_child_by_name’ Applied, thanks. signature.asc

  1   2   3   4   5   6   7   8   9   10   >