* [PATCH 3/5] gpiolib: remove duplicate pin range code
From: viresh kumar @ 2012-11-07 5:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352215014-30305-1-git-send-email-linus.walleij@stericsson.com>
On Tue, Nov 6, 2012 at 8:46 PM, Linus Walleij
<linus.walleij@stericsson.com> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> Commit 69e1601bca88809dc118abd1becb02c15a02ec71
> "gpiolib: provide provision to register pin ranges"
>
> Introduced both of_gpiochip_remove_pin_range() and
> gpiochip_remove_pin_ranges(). But the contents are exactly
> the same so remove the OF one and rely on the range deletion
> in the core.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
I can't believe that i did this :(
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH 4/5] gpiolib: call pin removal in chip removal function
From: viresh kumar @ 2012-11-07 5:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352215021-30341-1-git-send-email-linus.walleij@stericsson.com>
On Tue, Nov 6, 2012 at 8:47 PM, Linus Walleij
<linus.walleij@stericsson.com> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> This makes us call gpiochio_remove_pin_ranges() in the
> gpiochip_remove() function, so we get rid of ranges when
> freeing the chip.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
^ permalink raw reply
* [PATCH v2 5/6] ARM: davinci: remoteproc board support for OMAP-L138 DSP
From: Prabhakar Lad @ 2012-11-07 5:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <13514BD7FAEBA745BBD7D8A672905C14311F1E5E@DFLE08.ent.ti.com>
Hi Robert,
On Wed, Nov 7, 2012 at 1:03 AM, Tivy, Robert <rtivy@ti.com> wrote:
> Hi Prabhakar,
>
> Thanks for your consideration, please see my response below...
>
>> -----Original Message-----
>> From: Prabhakar Lad [mailto:prabhakar.csengg at gmail.com]
>> Sent: Monday, November 05, 2012 9:02 PM
>> To: Tivy, Robert; Ben Gardiner
>> Cc: davinci-linux-open-source at linux.davincidsp.com; linux-arm-
>> kernel at lists.infradead.org; Marek Szyprowski
>> Subject: Re: [PATCH v2 5/6] ARM: davinci: remoteproc board support for
>> OMAP-L138 DSP
>>
>> Hi Robert,
>>
>> On Thu, Nov 1, 2012 at 7:22 PM, Ben Gardiner
>> <bengardiner@nanometrics.ca> wrote:
>> > Hi Rob,
>> >
>> > On Thu, Oct 25, 2012 at 4:35 PM, Robert Tivy <rtivy@ti.com> wrote:
>> >> [...]
>> >> @@ -660,6 +667,99 @@ int __init da850_register_mmcsd1(struct
>> davinci_mmc_config *config)
>> >> }
>> >> #endif
>> >>
>> >> +static struct platform_device *da8xx_dsp;
>> >> +
>> >> +#ifdef CONFIG_CMA
>> >> +
>> >> +/*
>> >> + * The following address range was chosen because the XDC Platform
>> for
>> >> + * OMAP-L138 DSP has this range as its default code/data placement.
>> >> + */
>> >> +#define DA8XX_RPROC_CMA_BASE (0xc3000000)
>> >> [...]
>> >> +/*
>> >> + * The following address range was chosen because the XDC Platform
>> for
>> >> + * OMAP-L138 DSP has this range as its default code/data placement.
>> >> + *
>> >> + * System integrators must ensure that Linux does not own this
>> range.
>> >> + */
>> >> +#define DA_CONTIG_BASE (0xc3000000)
>> >> +#define DA_CONTIG_SIZE (0x02000000)
>> >
>> Is there a specific requirement for the dsp dev to have the buffers
>> from
>> this '0xc3000000' address range only ? If yes then
>> dma_declare_contiguous()
>> is must to ensure contiguous memory so the above macros cant be
>> avoided.
>> If there isn't a requirement of a specific region for dsp device you
>> can use a
>> global CMA instead, so as to ensure you have contiguous memory.
>
> The requirement is that the contiguous buffer matches the address range to which the DSP image was linked, including uninitialized sections that don't actually get loaded.
>
> I was thinking of making those #defines into Kconfig variables, so that kernel sources don't need to be touched by the end customer. Another alternative is to make them be kernel command line variables, which would prevent the need to even rebuild the kernel. What are your thoughts regarding those alternatives?
In either cases you still need a value which defaults, if the range was not
specified in command line or Kconfig value wasn?t set. In this case
you still need a macro with default value.
I would prefer passing the range as part of command line as it would
avoid rebuilding.
Regards,
--Prabhakar Lad
>
> The above address range was decided upon because it matches the RTSC platform's defined area for OMAP-L138 [1] (although, the customer can end up redefining that range). One of the reasons that range was chosen for the RTSC platform is that it exists on boards with smaller DDR sizes. In other words, for a board with 256MB of DDR, if a range at the top of the DDR address space was chosen then that DSP image wouldn't work with a board with only 128MB.
>
> Regards,
>
> - Rob
>
> [1] http://rtsc.eclipse.org/cdoc-tip/index.html#ti/platforms/evmOMAPL138/Platform.html#per-instance_config_parameters, however, we extended the range an additional 16MB beyond the RTSC platform's range.
>
>>
>> Regards,
>> --Prabhakar Lad
>>
>> > I am concerned with the rigidity of the memory hole as its definition
>> > is currently proposed.
>> >
>> > As you noted DA_CONTIG_BASE and DA_CONTIG_SIZE must describe a range
>> > that is not used by Linux. Ideally this hole would not be in the
>> > middle of the usuable memory but instead at the top. For L138 boards
>> > with larger DDR packages this would mean carrying a patch to this
>> > file.
>> >
>> > I think the same also applies to DA8XX_RPROC_CMA_BASE but I have no
>> > hands-on experience yet with CMA.
>> >
>> > Is there any other means by which the hole's location and size can be
>> > specified which does not require patching this file? I imagine
>> KConfig
>> > would work, but is this an acceptable use of KConfig?
>> >
>> > Best Regards,
>> > Ben Gardiner
>> >
>> > ---
>> > Nanometrics Inc.
>> > http://www.nanometrics.ca
>> > _______________________________________________
>> > Davinci-linux-open-source mailing list
>> > Davinci-linux-open-source at linux.davincidsp.com
>> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-
>> source
^ permalink raw reply
* [PATCH] Revert "ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints"
From: Shubhrajyoti Datta @ 2012-11-07 6:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211061619461.20573@utopia.booyaka.com>
On Tue, Nov 6, 2012 at 10:01 PM, Paul Walmsley <paul@pwsan.com> wrote:
>
> This reverts commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc.
> This commit causes I2C timeouts to appear on several OMAP3430/3530-based
> boards:
>
> http://marc.info/?l=linux-arm-kernel&m=135071372426971&w=2
> http://marc.info/?l=linux-arm-kernel&m=135067558415214&w=2
> http://marc.info/?l=linux-arm-kernel&m=135216013608196&w=2
>
> and appears to have been sent for merging before one of its prerequisites
> was merged:
>
> http://marc.info/?l=linux-arm-kernel&m=135219411617621&w=2
>
Not a comment however was curious does merging the dependency.
make the issue go away?
^ permalink raw reply
* [PATCH] ARM: cache-l2x0: move 'l2_wt_override' variable to proper place
From: Jingoo Han @ 2012-11-07 6:03 UTC (permalink / raw)
To: linux-arm-kernel
Fixed build warning as below:
arch/arm/mm/cache-l2x0.c:37:12: warning: 'l2_wt_override' defined but not used [-Wunused-variable]
Signed-off-by: Jingoo Han <jg1.han@samsung.com>
---
arch/arm/mm/cache-l2x0.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 92ee4a0..920a704 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -34,7 +34,6 @@ static DEFINE_RAW_SPINLOCK(l2x0_lock);
static u32 l2x0_way_mask; /* Bitmask of active ways */
static u32 l2x0_size;
static unsigned long sync_reg_offset = L2X0_CACHE_SYNC;
-static int l2_wt_override;
/* Aurora don't have the cache ID register available, so we have to
* pass it though the device tree */
@@ -429,6 +428,8 @@ void __init l2x0_init(void __iomem *base, u32 aux_val, u32 aux_mask)
* noninclusive, while the hardware cache range operations use
* inclusive start and end addresses.
*/
+static int l2_wt_override;
+
static unsigned long calc_range_end(unsigned long start, unsigned long end)
{
/*
--
1.7.1
^ permalink raw reply related
* [PATCH] spi: s3c64xx: Add fix for crash in spi suspend/resume
From: Naveen Krishna Chatradhi @ 2012-11-07 6:10 UTC (permalink / raw)
To: linux-arm-kernel
From: Abhilash Kesavan <a.kesavan@samsung.com>
The SPI driver makes a gpio_request during initialization. The requested
gpios need to be populated as part of the s3c64xx_spi_driver_data so that
they can be released during suspend and requested again during resume.
Add the missing code to save the requested gpios as part of the driver
data. This fixes a SPI driver suspend crash.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Naveen Krishna Chatradhi <ch.naveen@samsung.com>
---
This was tested on spi-next branch
http://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git
With S2R patches submitted on mailing list.
http://www.spinics.net/lists/arm-kernel/msg205244.html
drivers/spi/spi-s3c64xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index 01b2f56..57900a8 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -1112,7 +1112,7 @@ static int s3c64xx_spi_parse_dt_gpio(struct s3c64xx_spi_driver_data *sdd)
dev_err(dev, "invalid gpio[%d]: %d\n", idx, gpio);
goto free_gpio;
}
-
+ sdd->gpios[idx] = gpio;
ret = gpio_request(gpio, "spi-bus");
if (ret) {
dev_err(dev, "gpio [%d] request failed: %d\n",
--
1.7.9.5
^ permalink raw reply related
* possibility of parent clock selection through DT
From: Shiraz Hashim @ 2012-11-07 6:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi Mike, Rob,
Devices in a SoC can have multiple possible clock sources which is
perfectly captured through clk framework.
But the device itself may not be aware of the complex hierarchy above it.
In this case how do you suggest a board (through DT) should select its
preference.
Is there some work already going on in this direction ?
--
regards
Shiraz Hashim
^ permalink raw reply
* possibility of parent clock selection through DT
From: Shiraz Hashim @ 2012-11-07 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPub14-CPS48gQ1h8vvAYBpO_=egjheG_rMoZ894Y4XZ2CinUQ@mail.gmail.com>
On Wed, Nov 7, 2012 at 11:42 AM, Shiraz Hashim
<shiraz.linux.kernel@gmail.com> wrote:
> Hi Mike, Rob,
>
> Devices in a SoC can have multiple possible clock sources which is
> perfectly captured through clk framework.
>
> But the device itself may not be aware of the complex hierarchy above it.
> In this case how do you suggest a board (through DT) should select its
> preference.
>
> Is there some work already going on in this direction ?
Just to make it clear, I already have referred the clock DT bindings and
Shawn Guo patch on removing clk look up registration from kernel code.
Here I am talking about possibility of selecting desired clock hierarchy
by the boards about which device nodes are not aware.
--
regards
Shiraz Hashim
^ permalink raw reply
* [PATCH v2 2/2] mailbox: split internal header from API header
From: Omar Ramirez Luna @ 2012-11-07 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50990849.4050003@st.com>
Hi Loic,
On 6 November 2012 06:53, Loic PALLARDY <loic.pallardy@st.com> wrote:
>
>
> On 11/06/2012 03:55 AM, Omar Ramirez Luna wrote:
>> Now internal structures can remain hidden to the user and just API
>> related functions and defines are made available.
>>
>> Signed-off-by: Omar Ramirez Luna<omar.luna@linaro.org>
>> ---
>> drivers/mailbox/mailbox.c | 34 ++++++++++++++++++++++++++++++++
>> drivers/mailbox/mailbox.h | 48 +--------------------------------------------
>> include/linux/mailbox.h | 22 +++++++++++++++++++
> I agree with the file split but I think mailbox framework API should be
> more generic.
> omap_ prefix should not be used. mailbox_ prefix will be better.
Ok.
> Message type must be more opened like for example:
> struct mailbox_msg {
> int size;
> unsigned char header;
> unsigned char *pdata;
> };
We can analyze the requirement for having such structure, presumably
you expect variable size messages, in OMAP case it is a 4 byte value,
but I'm open to change in order to accommodate other users needs.
Cheers,
Omar
^ permalink raw reply
* [PATCH 00/10] serial: sh-sci fixes - console PM, SCIFB, SMP lockup, etc.
From: Shinya Kuribayashi @ 2012-11-07 6:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Paul and serial forks,
Here are sh-sci serial driver fixes that have been cooking for months
privately on my end:
* console PM rework with the help of serial-core's uart_change_pm()
* provide missing piece in SCIFB support (from Yoshii-san)
* address console write function vs. SMP lockup issue
and so on. Comments and suggestions are welcome.
Build tested with vanilla v3.6, but not boot- nor PM-tested with
newer kernels after v3.4. Anyone with can-sleep shmobile systems,
please give it try.
Thanks in advance,
----------------------------------------------------------------
Shinya Kuribayashi (5):
Revert "sh-sci / PM: Avoid deadlocking runtime PM"
Revert "sh-sci / PM: Use power.irq_safe"
Partially revert "serial: sh-sci: console Runtime PM support"
serial: sh-sci: add locking to console write function to avoid SMP lockup
serial: sh-sci: fix possible race cases on SCSCR register accesses
Takashi YOSHII (4):
serial: sh-sci: fix condition test to set SCBRR
serial: sh-sci: support lower baud rate
serial: sh-sci: mask SCTFDR/RFDR according to fifosize
serial: sh-sci: fix common SCIFB regmap definition
Teppei Kamijou (1):
serial: sh-sci: console runtime PM support (revisit)
drivers/tty/serial/sh-sci.c | 140 ++++++++++++++++++--------------------------
1 file changed, 56 insertions(+), 84 deletions(-)
--
Shinya Kuribayashi
Renesas Electronics
^ permalink raw reply
* [PATCH 01/10] Revert "sh-sci / PM: Avoid deadlocking runtime PM"
From: Shinya Kuribayashi @ 2012-11-07 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
This reverts commit 048be431e4 (sh-sci / PM: Avoid deadlocking runtime
PM, from Rafael J. Wysocki <rjw@sisk.pl>, 2012-03-09).
In order to get console PM work properly, we should implement uart_ops
->pm() operation, rather than sprinkle band-ading runtime PM calls in
the driver.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 9be296c..526ad04 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1752,8 +1752,6 @@ static int sci_startup(struct uart_port *port)
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
- pm_runtime_put_noidle(port->dev);
-
sci_port_enable(s);
ret = sci_request_irq(s);
@@ -1781,8 +1779,6 @@ static void sci_shutdown(struct uart_port *port)
sci_free_irq(s);
sci_port_disable(s);
-
- pm_runtime_get_noresume(port->dev);
}
static unsigned int sci_scbrr_calc(unsigned int algo_id, unsigned int bps,
@@ -2121,7 +2117,6 @@ static int __devinit sci_init_single(struct platform_device *dev,
sci_init_gpios(sci_port);
pm_runtime_irq_safe(&dev->dev);
- pm_runtime_get_noresume(&dev->dev);
pm_runtime_enable(&dev->dev);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH 02/10] Revert "sh-sci / PM: Use power.irq_safe"
From: Shinya Kuribayashi @ 2012-11-07 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
This reverts commit 5a50a01bf0 (sh-sci / PM: Use power.irq_safe, from
Rafael J. Wysocki <rjw@sisk.pl>, 2011-08-24).
In order to get console PM work properly, we should implement uart_ops
->pm() operation, rather than sprinkle band-ading runtime PM calls in
the driver.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 526ad04..9abe977 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2116,7 +2116,6 @@ static int __devinit sci_init_single(struct platform_device *dev,
sci_init_gpios(sci_port);
- pm_runtime_irq_safe(&dev->dev);
pm_runtime_enable(&dev->dev);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH 03/10] Partially revert "serial: sh-sci: console Runtime PM support"
From: Shinya Kuribayashi @ 2012-11-07 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
This partially reverts commit 1ba7622094 (serial: sh-sci: console
Runtime PM support, from Magnus Damm <damm@opensource.se>, 2011-08-03).
The generic 'serial_core' can take care of console PM maintenance,
so all (or at least the first thing) we have to do to get console PM
work properly, is to implement uart_ops ->pm() operation in the sh-sci
serial client driver.
This patch partially reverts the commit above, but leaving sci_reset()
change in place, because sci_reset() is already part of another commit
(73c3d53f38 serial: sh-sci: Avoid FIFO clear for MCE toggle.).
A revised version of console PM support follows next.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 53 +--------------------------------------------
1 file changed, 1 insertion(+), 52 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 9abe977..e9e8883 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -99,12 +99,6 @@ struct sci_port {
#endif
struct notifier_block freq_transition;
-
-#ifdef CONFIG_SERIAL_SH_SCI_CONSOLE
- unsigned short saved_smr;
- unsigned short saved_fcr;
- unsigned char saved_brr;
-#endif
};
/* Function prototypes */
@@ -2247,8 +2241,7 @@ static int __devinit serial_console_setup(struct console *co, char *options)
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
- sci_port_disable(sci_port);
-
+ /* TODO: disable clock */
return uart_set_options(port, co, baud, parity, bits, flow);
}
@@ -2291,46 +2284,6 @@ static int __devinit sci_probe_earlyprintk(struct platform_device *pdev)
return 0;
}
-#define uart_console(port) ((port)->cons->index == (port)->line)
-
-static int sci_runtime_suspend(struct device *dev)
-{
- struct sci_port *sci_port = dev_get_drvdata(dev);
- struct uart_port *port = &sci_port->port;
-
- if (uart_console(port)) {
- struct plat_sci_reg *reg;
-
- sci_port->saved_smr = serial_port_in(port, SCSMR);
- sci_port->saved_brr = serial_port_in(port, SCBRR);
-
- reg = sci_getreg(port, SCFCR);
- if (reg->size)
- sci_port->saved_fcr = serial_port_in(port, SCFCR);
- else
- sci_port->saved_fcr = 0;
- }
- return 0;
-}
-
-static int sci_runtime_resume(struct device *dev)
-{
- struct sci_port *sci_port = dev_get_drvdata(dev);
- struct uart_port *port = &sci_port->port;
-
- if (uart_console(port)) {
- sci_reset(port);
- serial_port_out(port, SCSMR, sci_port->saved_smr);
- serial_port_out(port, SCBRR, sci_port->saved_brr);
-
- if (sci_port->saved_fcr)
- serial_port_out(port, SCFCR, sci_port->saved_fcr);
-
- serial_port_out(port, SCSCR, sci_port->cfg->scscr);
- }
- return 0;
-}
-
#define SCI_CONSOLE (&serial_console)
#else
@@ -2340,8 +2293,6 @@ static inline int __devinit sci_probe_earlyprintk(struct platform_device *pdev)
}
#define SCI_CONSOLE NULL
-#define sci_runtime_suspend NULL
-#define sci_runtime_resume NULL
#endif /* CONFIG_SERIAL_SH_SCI_CONSOLE */
@@ -2459,8 +2410,6 @@ static int sci_resume(struct device *dev)
}
static const struct dev_pm_ops sci_dev_pm_ops = {
- .runtime_suspend = sci_runtime_suspend,
- .runtime_resume = sci_runtime_resume,
.suspend = sci_suspend,
.resume = sci_resume,
};
--
1.7.12.4
^ permalink raw reply related
* [PATCH 04/10] serial: sh-sci: console runtime PM support (revisit)
From: Shinya Kuribayashi @ 2012-11-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
The commit 1ba7622094 (serial: sh-sci: console Runtime PM support,
from Magnus Damm <damm@opensource.se>, 2011-08-03), tried to support
console runtime PM, but unfortunately it didn't work for us for some
reason. We did not investigated further at that time, instead would
like to propose a different approach.
In Linux tty/serial world, to get console PM work properly, a serial
client driver does not have to maintain .runtime_suspend()/..resume()
calls itself, but can leave console power power management handling to
the serial core driver.
This patch moves the sh-sci driver in that direction.
Notes:
* There is room to optimize console runtime PM more aggressively by
maintaining additional local runtime PM calls, but as a first step
having .pm() operation would suffice.
* We still have a couple of direct calls to sci_port_enable/..disable
left in the driver. We have to live with them, because they're out
of serial core's help.
Signed-off-by: Teppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 27 ++++++++++++++++-----------
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index e9e8883..e65e546 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1746,8 +1746,6 @@ static int sci_startup(struct uart_port *port)
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
- sci_port_enable(s);
-
ret = sci_request_irq(s);
if (unlikely(ret < 0))
return ret;
@@ -1771,8 +1769,6 @@ static void sci_shutdown(struct uart_port *port)
sci_free_dma(port);
sci_free_irq(s);
-
- sci_port_disable(s);
}
static unsigned int sci_scbrr_calc(unsigned int algo_id, unsigned int bps,
@@ -1921,6 +1917,21 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
sci_port_disable(s);
}
+static void sci_pm(struct uart_port *port, unsigned int state,
+ unsigned int oldstate)
+{
+ struct sci_port *sci_port = to_sci_port(port);
+
+ switch (state) {
+ case 3:
+ sci_port_disable(sci_port);
+ break;
+ default:
+ sci_port_enable(sci_port);
+ break;
+ }
+}
+
static const char *sci_type(struct uart_port *port)
{
switch (port->type) {
@@ -2042,6 +2053,7 @@ static struct uart_ops sci_uart_ops = {
.startup = sci_startup,
.shutdown = sci_shutdown,
.set_termios = sci_set_termios,
+ .pm = sci_pm,
.type = sci_type,
.release_port = sci_release_port,
.request_port = sci_request_port,
@@ -2195,16 +2207,12 @@ static void serial_console_write(struct console *co, const char *s,
struct uart_port *port = &sci_port->port;
unsigned short bits;
- sci_port_enable(sci_port);
-
uart_console_write(port, s, count, serial_console_putchar);
/* wait until fifo is empty and last bit has been transmitted */
bits = SCxSR_TDxE(port) | SCxSR_TEND(port);
while ((serial_port_in(port, SCxSR) & bits) != bits)
cpu_relax();
-
- sci_port_disable(sci_port);
}
static int __devinit serial_console_setup(struct console *co, char *options)
@@ -2236,12 +2244,9 @@ static int __devinit serial_console_setup(struct console *co, char *options)
if (unlikely(ret != 0))
return ret;
- sci_port_enable(sci_port);
-
if (options)
uart_parse_options(options, &baud, &parity, &bits, &flow);
- /* TODO: disable clock */
return uart_set_options(port, co, baud, parity, bits, flow);
}
--
1.7.12.4
^ permalink raw reply related
* [PATCH 05/10] serial: sh-sci: fix condition test to set SCBRR
From: Shinya Kuribayashi @ 2012-11-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
SCBRR == 0 is valid value (divide by 1).
Signed-off-by: Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index e65e546..ffeca65 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1853,7 +1853,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
dev_dbg(port->dev, "%s: SMR %x, t %x, SCSCR %x\n", __func__, smr_val, t,
s->cfg->scscr);
- if (t > 0) {
+ if (t >= 0) {
if (t >= 256) {
serial_port_out(port, SCSMR, (serial_port_in(port, SCSMR) & ~3) | 1);
t >>= 2;
--
1.7.12.4
^ permalink raw reply related
* [PATCH 06/10] serial: sh-sci: support lower baud rate
From: Shinya Kuribayashi @ 2012-11-07 6:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
Support prescaler 1/16 and 1/64, in addition to current 1 and 1/4.
Supporting below 2400bps was dropped long time ago in mainline.
Since then, setting lower rate has been resulting in erroneous
register value, without indicating any errors through API.
This patch adds more prescaler to support lower rates again.
This still doesn't check range, but we won't hit the case because
even 50bps at 48MHz clock is now supported.
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 19 ++++++++-----------
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index ffeca65..3021912 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1814,7 +1814,7 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
{
struct sci_port *s = to_sci_port(port);
struct plat_sci_reg *reg;
- unsigned int baud, smr_val, max_baud;
+ unsigned int baud, smr_val, max_baud, cks;
int t = -1;
/*
@@ -1848,21 +1848,18 @@ static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
uart_update_timeout(port, termios->c_cflag, baud);
- serial_port_out(port, SCSMR, smr_val);
+ for (cks = 0; t >= 256 && cks <= 3; cks++)
+ t >>= 2;
- dev_dbg(port->dev, "%s: SMR %x, t %x, SCSCR %x\n", __func__, smr_val, t,
- s->cfg->scscr);
+ dev_dbg(port->dev, "%s: SMR %x, cks %x, t %x, SCSCR %x\n",
+ __func__, smr_val, cks, t, s->cfg->scscr);
if (t >= 0) {
- if (t >= 256) {
- serial_port_out(port, SCSMR, (serial_port_in(port, SCSMR) & ~3) | 1);
- t >>= 2;
- } else
- serial_port_out(port, SCSMR, serial_port_in(port, SCSMR) & ~3);
-
+ serial_port_out(port, SCSMR, (smr_val & ~3) | cks);
serial_port_out(port, SCBRR, t);
udelay((1000000+(baud-1)) / baud); /* Wait one bit interval */
- }
+ } else
+ serial_port_out(port, SCSMR, smr_val);
sci_init_pins(port, termios->c_cflag);
--
1.7.12.4
^ permalink raw reply related
* [PATCH 07/10] serial: sh-sci: mask SCTFDR/RFDR according to fifosize
From: Shinya Kuribayashi @ 2012-11-07 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
Current mask 0xff to SCTFDR/RFDR damages SCIFB, because the
registers on SCIFB have 9-bit data (0 to 256).
This patch changes the mask according to port->fifosize.
Though I'm not sure if the mask is really needed (I don't know if
there are variants which have non-zero upper bits), it is safer.
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 3021912..63a3bd0 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -485,7 +485,7 @@ static int sci_txfill(struct uart_port *port)
reg = sci_getreg(port, SCTFDR);
if (reg->size)
- return serial_port_in(port, SCTFDR) & 0xff;
+ return serial_port_in(port, SCTFDR) & ((port->fifosize << 1) - 1);
reg = sci_getreg(port, SCFDR);
if (reg->size)
@@ -505,7 +505,7 @@ static int sci_rxfill(struct uart_port *port)
reg = sci_getreg(port, SCRFDR);
if (reg->size)
- return serial_port_in(port, SCRFDR) & 0xff;
+ return serial_port_in(port, SCRFDR) & ((port->fifosize << 1) - 1);
reg = sci_getreg(port, SCFDR);
if (reg->size)
--
1.7.12.4
^ permalink raw reply related
* [PATCH 08/10] serial: sh-sci: fix common SCIFB regmap definition
From: Shinya Kuribayashi @ 2012-11-07 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
About FIFO count, there are two variants of SCIFs which show
a) TX count in upper, RX count in lower byte of FDR register
b) TX count in TFDR register, RX count in RFDR register
Common SCIFB regmap in current source code is defined as "a".
At least 7372 and 73a0 HW manual say their SICFB are "b".
This patch alters the definition to "b", considering the current
one has come from a mistake. The reason is as follows.
The flag SCIFB sh-sci driver means it has 256 byte FIFO.
The count is from 0(empty) to 256(full), that makes 9-bit.
Because FDR is 16-bit register, it can not hold two 9-bits.
That's why, SCIFB can not be "a".
Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 63a3bd0..502fa47 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -196,9 +196,9 @@ static struct plat_sci_reg sci_regmap[SCIx_NR_REGTYPES][SCIx_NR_REGS] = {
[SCxSR] = { 0x14, 16 },
[SCxRDR] = { 0x60, 8 },
[SCFCR] = { 0x18, 16 },
- [SCFDR] = { 0x1c, 16 },
- [SCTFDR] = sci_reg_invalid,
- [SCRFDR] = sci_reg_invalid,
+ [SCFDR] = sci_reg_invalid,
+ [SCTFDR] = { 0x38, 16 },
+ [SCRFDR] = { 0x3c, 16 },
[SCSPTR] = sci_reg_invalid,
[SCLSR] = sci_reg_invalid,
},
--
1.7.12.4
^ permalink raw reply related
* [PATCH 09/10] serial: sh-sci: add locking to console write function to avoid SMP lockup
From: Shinya Kuribayashi @ 2012-11-07 7:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
Symptom:
When entering the suspend with Android logcat running, printk() call
gets stuck and never returns. The issue can be observed at printk()s
on nonboot CPUs when going to offline with their interrupts disabled,
and never seen at boot CPU (core0 in our case).
Details:
serial_console_write() lacks of appropriate spinlock handling.
In SMP systems, as long as sci_transmit_chars() is being processed
at one CPU core, serial_console_write() can stuck at the other CPU
core(s), when it tries to access to the same serial port _without_
a proper locking. serial_console_write() waits for the transmit FIFO
getting empty, while sci_transmit_chars() writes data to the FIFO.
In general, peripheral interrupts are routed to boot CPU (core0) by
Linux ARM standard affinity settings. SCI(F) interrupts are handled
by core0, so sci_transmit_chars() is processed on core0 as well.
When logcat is running, it writes enormous log data to the kernel at
every moment, forever. So core0 can repeatedly continue to process
sci_transmit_chars() in its interrupt handler, which eventually makes
the other CPU core(s) stuck at serial_console_write().
Looking at serial/8250.c, this is a known console write lockup issue
with SMP kernels. Fix the sh-sci driver in the same way 8250.c does.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
|commit ef605fdb33883d687cff5ba75095a91b313b4966
|Author: Rabin Vincent <rabin.vincent@stericsson.com>
|Date: Tue Jan 17 11:52:28 2012 +0100
|
| serial: amba-pl011: lock console writes against interrupts
|commit 9ec1882df244c4ee1baa692676fef5e8b0f5487d
|Author: Xinyu Chen <xinyu.chen@freescale.com>
|Date: Mon Aug 27 09:36:51 2012 +0200
|
| tty: serial: imx: console write routing is unsafe on SMP
---
drivers/tty/serial/sh-sci.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 502fa47..0b8d029 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2202,7 +2202,21 @@ static void serial_console_write(struct console *co, const char *s,
{
struct sci_port *sci_port = &sci_ports[co->index];
struct uart_port *port = &sci_port->port;
- unsigned short bits;
+ unsigned short bits, ctrl;
+ unsigned long flags;
+ int locked = 1;
+
+ local_irq_save(flags);
+ if (port->sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&port->lock);
+ else
+ spin_lock(&port->lock);
+
+ /* first save the SCSCR then disable the interrupts */
+ ctrl = serial_port_in(port, SCSCR);
+ serial_port_out(port, SCSCR, sci_port->cfg->scscr);
uart_console_write(port, s, count, serial_console_putchar);
@@ -2210,6 +2224,13 @@ static void serial_console_write(struct console *co, const char *s,
bits = SCxSR_TDxE(port) | SCxSR_TEND(port);
while ((serial_port_in(port, SCxSR) & bits) != bits)
cpu_relax();
+
+ /* restore the SCSCR */
+ serial_port_out(port, SCSCR, ctrl);
+
+ if (locked)
+ spin_unlock(&port->lock);
+ local_irq_restore(flags);
}
static int __devinit serial_console_setup(struct console *co, char *options)
--
1.7.12.4
^ permalink raw reply related
* [PATCH 10/10] serial: sh-sci: fix possible race cases on SCSCR register accesses
From: Shinya Kuribayashi @ 2012-11-07 7:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
In the previous commit, console write function (serial_console_write)
is changed to disable SCI interrupts while printing console strings.
This introduces possible race cases in the serial startup / shutdown
functions on SMP systems.
This patch fixes the sh-sci in the same way as commit 9ec1882df2
(tty: serial: imx: console write routing is unsafe on SMP, from
Xinyu Chen <xinyu.chen@freescale.com>, 2012-08-27) did.
There could be several consumers of the console,
* the kernel printk
* the init process using /dev/kmsg to call printk to show log
* shell, which opens /dev/console and writes with sys_write()
The shell goes into the normal UART open() and write() system calls,
while the other two go into the console operations. The open() call
invokes serial startup function (sci_startup), which will write to
the SCSCR register (to enable or disable SCI interrupts) without any
locking. This will conflict with the console serial function.
Add spinlock protections in sci_startup() and sci_shutdown() properly.
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
---
drivers/tty/serial/sh-sci.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 0b8d029..8e3c7f7 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1742,6 +1742,7 @@ static inline void sci_free_dma(struct uart_port *port)
static int sci_startup(struct uart_port *port)
{
struct sci_port *s = to_sci_port(port);
+ unsigned long flags;
int ret;
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
@@ -1752,8 +1753,10 @@ static int sci_startup(struct uart_port *port)
sci_request_dma(port);
+ spin_lock_irqsave(&port->lock, flags);
sci_start_tx(port);
sci_start_rx(port);
+ spin_unlock_irqrestore(&port->lock, flags);
return 0;
}
@@ -1761,11 +1764,14 @@ static int sci_startup(struct uart_port *port)
static void sci_shutdown(struct uart_port *port)
{
struct sci_port *s = to_sci_port(port);
+ unsigned long flags;
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
+ spin_lock_irqsave(&port->lock, flags);
sci_stop_rx(port);
sci_stop_tx(port);
+ spin_unlock_irqrestore(&port->lock, flags);
sci_free_dma(port);
sci_free_irq(s);
--
1.7.12.4
^ permalink raw reply related
* [PATCH v3 2/4] arm: bcm2835: convert to the irqchip infrastructure
From: Thomas Petazzoni @ 2012-11-07 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106165639.GF1254@beefymiracle.amer.corp.natinst.com>
Josh,
On Tue, 6 Nov 2012 10:56:39 -0600, Josh Cartwright wrote:
> Could it make sense here to kill the irqchip.h private export, and
> instead rely on the linker to stitch together the builtin irqchip's
> of_device_id tables?
Yes, using yet another ELF section is another option to do that. I just
wasn't sure it was worth the effort for now, but if it is seen as
necessary, I can certainly go ahead and implement this.
I am at ELCE at the moment, so quite busy with talks, discussions...
and drinks. I'll get back to this when I get back from ELCE.
Thanks for your suggestion,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* scheduler clock for MXS
From: Shawn Guo @ 2012-11-07 7:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106224624.GR28327@n2100.arm.linux.org.uk>
On Tue, Nov 06, 2012 at 10:46:24PM +0000, Russell King - ARM Linux wrote:
> On Tue, Nov 06, 2012 at 11:30:44PM +0100, Stanislav Meduna wrote:
> > On 06.11.2012 21:20, Russell King - ARM Linux wrote:
> > > Well. I just tried an experiment with OMAP4:
> > > [ 0.000000] sched_clock: 16 bits at 32kHz, resolution 30517ns,
> > wraps every 1999ms
> > > ...
> > > [ 3.070404] Freeing init memory: 192K
> >
> >
> > OK, so it is not a 16-bit problem either. So where is the
> > difference? Could it be that HZ / NO_HZ is playing some
> > tricks here and need to be taken into consideration?
> >
> > I'll try to artificially limit the counter-reading function
> > on my hardware to 16 bits and look whether I can also
> > reproduce this - probably on Thursday or Friday earliest
> > (busy with other tasks now).
> >
> > If it works I'll resubmit for only the iMX.28 and someone
> > who actually has the iMX.23 hardware to experiment with has
> > to look at it; the best start is probably to start with
> > comparing it to the working OMAP4. If it does not I'll
> > try to find the culprit.
>
> I wonder if the NO_HZ slack is preventing the sched_clock epoch update
> from happening in time. Hmm.
>
> * round_jiffies - function to round jiffies to a full second
>
> This is probably it. With mine, it's a 32.768kHz clock, so limiting
> it to 16-bit gives a wrap period of 2 seconds exactly. We take 10%
> off, so the timer would be asked to fire every 1.8s, which would be
> rounded up to 2 seconds. That's a little too close for comfort...
>
> Yours on the other hand:
>
> sched_clock: 16 bits at 32kHz, resolution 31250ns, wraps every 2047ms
>
> says that this timer runs at _exactly_ 32kHz (are you sure? If this is
It sources from 24 MHz crystal with a fixed divider 750, so it's
24000000 / 750 = 32000.
Shawn
> generated from a separate 32k crystal oscilator, it's most likely
> 32.768kHz because that's the standard crystal frequency. In any case,
> this would give a wrap period of just over 2 seconds.
>
> But remember, we take of 10%, so this would give 1843ms. Jiffy
> conversion would give 185 jiffies, and rounded up to a second gives
> 200 jiffies, so again 2 seconds.
>
> I suspect that your timer _does_ run at approximately 32768kHz, meaning
> that it _does_ roll over at 2 second intervals. But maybe it's trimmed
> to be slightly fast or maybe your kernel's idea of time is slightly
> slow - either one of which would then give you this effect.
>
> However, either way, rounding 1.8s up to 2s for a 16-bit 32768kHz
> counter isn't going to give reliable results.
>
> I think in this case, we need a version of round_jiffies() which _always_
> rounds down. Unfortunately, it doesn't exist. Thomas? What are the
> options here?
^ permalink raw reply
* [PATCH 00/10] serial: sh-sci fixes - console PM, SCIFB, SMP lockup, etc.
From: Shinya Kuribayashi @ 2012-11-07 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509A0658.1010503@renesas.com>
On 11/7/2012 3:57 PM, Shinya Kuribayashi wrote:
> Hi Paul and serial forks,
[...]
> Takashi YOSHII (4):
> serial: sh-sci: fix condition test to set SCBRR
> serial: sh-sci: support lower baud rate
> serial: sh-sci: mask SCTFDR/RFDR according to fifosize
> serial: sh-sci: fix common SCIFB regmap definition
>
> Teppei Kamijou (1):
> serial: sh-sci: console runtime PM support (revisit)
>
> drivers/tty/serial/sh-sci.c | 140 ++++++++++++++++++--------------------------
> 1 file changed, 56 insertions(+), 84 deletions(-)
Oops, I forgot to append proper From: author lines in five commits
(patch 04/10 to 09/10). Didn't mean to supersede your authoship.
I'd respin the patchset later, waiting for some feedback.
--
Shinya Kuribayashi
Renesas Electronics
^ permalink raw reply
* [PATCH 08/10] pinctrl: single: support pinconf generic
From: Haojian Zhuang @ 2012-11-07 7:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121101004406.GJ15766@atomide.com>
On Thursday, November 1, 2012, Tony Lindgren wrote:
>
> > --- a/drivers/pinctrl/pinctrl-single.c
> > +++ b/drivers/pinctrl/pinctrl-single.c
> > @@ -20,6 +20,7 @@
> > #include <linux/of_device.h>
> > #include <linux/of_address.h>
> >
> > +#include <linux/pinctrl/pinconf-generic.h>
> > #include <linux/pinctrl/pinctrl.h>
> > #include <linux/pinctrl/pinmux.h>
> >
> > @@ -28,6 +29,9 @@
> > #define DRIVER_NAME "pinctrl-single"
> > #define PCS_MUX_PINS_NAME "pinctrl-single,pins"
> > #define PCS_MUX_BITS_NAME "pinctrl-single,bits"
> > +#define PCS_BIAS_NAME "pinctrl-single,bias"
> > +#define PCS_POWER_SOURCE_NAME "pinctrl-single,power-source"
> > +#define PCS_SCHMITT_NAME "pinctrl-single,input-schmitt"
> > #define PCS_REG_NAME_LEN ((sizeof(unsigned long) * 2) + 1)
> > #define PCS_OFF_DISABLED ~0U
> > #define PCS_MAX_GPIO_VALUES 3
>
> Here too you can remove the new defines.
>
> > static int pcs_parse_one_pinctrl_entry(struct pcs_device *pcs,
> > struct device_node *np,
> > struct pinctrl_map **map,
> > + unsigned num_configs,
> > const char **pgnames)
> > {
> ...
>
> Then I suggest you add a generic pinconf-generic property to
> indicate the controller supports pinconf. At least for omaps,
> only some register ranges support pinconf. And by adding
> pinconf-generic, you can parse it once during the probe of
> pinctrl-single.c, and set pcs->pinconf flag.
>
> Then you can use here and avoid calling of_property_read_u32
> for about 600 times unnecessarily for omap4:
>
I don't want to add new property for this. I think that we can use
compatible name instead.
"pinctrl-single" is only for pinmux & gpio range.
"pinconf-single" is for pinmux & gpio range & generic pinconf.
^ permalink raw reply
* [RFC patch v3 3/4] ASoC: atmel-ssc-dai: register dai and pcm directly
From: Bo Shen @ 2012-11-07 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121106113908.GC10080@opensource.wolfsonmicro.com>
On 11/6/2012 19:39, Mark Brown wrote:
> On Tue, Nov 06, 2012 at 05:32:32PM +0800, Bo Shen wrote:
>> On 11/6/2012 16:48, Mark Brown wrote:
>>> On Tue, Nov 06, 2012 at 01:57:53PM +0800, Bo Shen wrote:
>
>>> No, this isn't converting things to device tree which presumably is the
>>> goal here and obviously just doing the rename doesn't accomplish an
>>> enormous amount. What I said was that you should instantiate the ASoC
>>> adaption when the machine driver needs to use them. You shouldn't even
>>> need a separate device for this.
>
>> Maybe this is not the best solution, but just abstract audio as a
>> separate device. The other's still keep as a ssc library.
>
> It's not abstracting things, that's the whole problem. It's putting the
> internals of how the Linux audio stack is organised into the device
> tree. The point is that the SSC should be a library to all users.
OK. I will keep the SSC as a library for all users.
>>> Please do look at other platforms with similar hardware and do something
>>> similar to them.
>
>> I take some reference (e.g: freescale, marvell, invidia soc, this
>> RFC implement is similar with them), but don't find the similar
>> hardware with us. Please help provide the information who's HW is
>> similar with us. Thanks.
>
> A *huge* range of SoCs have generic serial ports - off the top of my
> head this includes at least OMAP, PXA and Freescale. The same issue
> also applies to DMA controllers which affects almost all SoCs.
Thanks for this information, I will try to implement the SSC framework
like this. If it is finished, I will send out v4 patch series.
Thanks again.
BRs,
Bo Shen
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox