* [PATCH] i2c: change the id to let the i2c device work
From: Bo Shen @ 2012-10-12 7:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012091427.0d7b2bed@endymion.delvare>
Hi Jean Delvare,
On 10/12/2012 15:14, Jean Delvare wrote:
> On Fri, 12 Oct 2012 14:53:02 +0900, Mark Brown wrote:
>> On Fri, Oct 12, 2012 at 01:45:48PM +0800, Bo Shen wrote:
>>> So, in this case, if the id = -1, i2c core will dynamically assign a
>>> bus id to this bus when running, the dynamically assigned bus id is
>>> unknown when writing the code. So, when we use
>>> i2c_register_board_info(int busnum, ...) to register device on
>>> busnum. we don't know which value to be use.
>>
>> The I2C bus number assigned to the controller should be independant of
>> the platform device ID used to register the device; a better fix if this
>> is an issue would be to update the i2c-gpio driver to allow a fixed bus
>> number to be specified in platform data.
>
> i2c-gpio does support this already.
vim I only see the i2c-gpio platform data structure as following:
--<---------------------
struct i2c_gpio_platform_data {
unsigned int sda_pin;
unsigned int scl_pin;
int udelay;
int timeout;
unsigned int sda_is_open_drain:1;
unsigned int scl_is_open_drain:1;
unsigned int scl_is_output_only:1;
};
-->---------------------
So, how to allow a fixed bus number to be specified in platform data?
^ permalink raw reply
* [PATCH 1/6] ARM: bcm476x: Add infrastructure
From: Arnd Bergmann @ 2012-10-12 8:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012092617.37e82610@skate>
On Friday 12 October 2012, Thomas Petazzoni wrote:
> My understanding is that all virtual address constants should now be
> defined to have the void __iomem * type (i.e, using IOMEM). In the
> future, the idea is that map_desc.virtual might be switched to the void
> __iomem * type as well.
>
> But others (Arnd?) will confirm (or not) this.
I would certainly like to see this, yes. I had a patch for it ages ago,
but would start over again if I did this now.
I don't have time to do the conversion at the moment, but I would certainly
welcome a patch that does it. I can give some details about the problems
with that and how I think they should be solved.
Arnd
^ permalink raw reply
* [PATCH] i2c: change the id to let the i2c device work
From: Jean Delvare @ 2012-10-12 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5077CCF4.7070104@atmel.com>
On Fri, 12 Oct 2012 15:55:32 +0800, Bo Shen wrote:
> vim I only see the i2c-gpio platform data structure as following:
> --<---------------------
> struct i2c_gpio_platform_data {
> unsigned int sda_pin;
> unsigned int scl_pin;
> int udelay;
> int timeout;
> unsigned int sda_is_open_drain:1;
> unsigned int scl_is_open_drain:1;
> unsigned int scl_is_output_only:1;
> };
> -->---------------------
Ah sorry I misread Mark's request. i2c-gpio will turn the platform
device ID into bus number, it can indeed not be forced through platform
data. But I don't think any other i2c bus driver allows this either. I
don't quite see the problem with setting a platform device ID even if
there's only one instance of the platform device. I have many examples
of this on my machine:
Fixed MDIO bus.0
coretemp.0
vesafb.0
So please just set the platform device ID to 0 (or whatever i2c adapter
number you want) and your problem is solved. As you just proposed
initially, actually :)
--
Jean Delvare
^ permalink raw reply
* alignment faults in 3.6
From: Arnd Bergmann @ 2012-10-12 8:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <yw1xtxu1nfsn.fsf@unicorn.mansr.com>
On Thursday 11 October 2012, M?ns Rullg?rd wrote:
> > But, the IP header is expected to be aligned.
>
> Everything tells the compiler the struct is perfectly aligned. When the
> buggy driver passes a misaligned pointer, bad things happen.
Would it be appropriate to add a WARN_ON_ONCE() in the alignment fault path
then? If all alignment faults in the kernel are caused by broken drivers,
that would at least give us some hope of finding those drivers while at the
same time not causing much overhead in the case where we need to do the
fixup in the meantime.
Arnd
^ permalink raw reply
* [PATCH 1/6] ARM: bcm476x: Add infrastructure
From: Thomas Petazzoni @ 2012-10-12 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210120803.54539.arnd@arndb.de>
Arnd,
On Fri, 12 Oct 2012 08:03:54 +0000, Arnd Bergmann wrote:
> I would certainly like to see this, yes. I had a patch for it ages
> ago, but would start over again if I did this now.
>
> I don't have time to do the conversion at the moment, but I would
> certainly welcome a patch that does it. I can give some details about
> the problems with that and how I think they should be solved.
I did start working on such a patch a few weeks ago, but converting all
the platforms to use IOMEM() was really boring. But now you did that, I
can try to revive my patch, see if it works, and post it if you're
interested.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH] i2c: change the id to let the i2c device work
From: Mark Brown @ 2012-10-12 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012100521.64cb9adb@endymion.delvare>
On Fri, Oct 12, 2012 at 10:05:21AM +0200, Jean Delvare wrote:
> Ah sorry I misread Mark's request. i2c-gpio will turn the platform
> device ID into bus number, it can indeed not be forced through platform
> data. But I don't think any other i2c bus driver allows this either. I
> don't quite see the problem with setting a platform device ID even if
> there's only one instance of the platform device. I have many examples
> of this on my machine:
> Fixed MDIO bus.0
> coretemp.0
> vesafb.0
This is generally bad style; if it's required by APIs we really should
be fixing the APIs to remove this sort of dependency. Aside from the
ugliness it tends to be fragile.
> So please just set the platform device ID to 0 (or whatever i2c adapter
> number you want) and your problem is solved. As you just proposed
> initially, actually :)
Though it *does* need a comprehensible commit message so people can
understand what on earth the change is intended to do.
^ permalink raw reply
* [PATCH 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Andy Shevchenko @ 2012-10-12 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <91e41b4cc972d298f714cbd6f400569a9710304c.1350020375.git.viresh.kumar@linaro.org>
On Fri, 2012-10-12 at 11:14 +0530, Viresh Kumar wrote:
> dw_dmac driver already supports device tree but it used to have its platform
> data passed the non-DT way.
My few comments are below.
>
> This patch does following changes:
> - pass platform data via DT, non-DT way still takes precedence if both are used.
> - create generic filter routine
> - Earlier slave information was made available by slave specific filter routines
> in chan->private field. Now, this information would be passed from within dmac
> DT node. Slave drivers would now be required to pass bus_id (a string) as
> parameter to this generic filter(), which would be compared against the slave
> data passed from DT, by the generic filter routine.
> - Update binding document
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> Documentation/devicetree/bindings/dma/snps-dma.txt | 44 ++++++
> drivers/dma/dw_dmac.c | 147 +++++++++++++++++++++
> drivers/dma/dw_dmac_regs.h | 4 +
> include/linux/dw_dmac.h | 43 +++---
> 4 files changed, 221 insertions(+), 17 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
> index c0d85db..5bb3dfb 100644
> --- a/Documentation/devicetree/bindings/dma/snps-dma.txt
> +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
> @@ -6,6 +6,26 @@ Required properties:
> - interrupt-parent: Should be the phandle for the interrupt controller
> that services interrupts for this device
> - interrupt: Should contain the DMAC interrupt number
> +- nr_channels: Number of channels supported by hardware
> +- is_private: The device channels should be marked as private and not for by the
> + general purpose DMA channel allocator. False if not passed.
> +- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
> + 1: descending
> +- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
> + increase from chan n->0
> +- block_size: Maximum block size supported by the controller
> +- nr_masters: Number of AHB masters supported by the controller
> +- data_width: Maximum data width supported by hardware per AHB master
> + (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
> +- slave_info:
> + - bus_id: name of this device channel, not just a device name since
> + devices may have more than one channel e.g. "foo_tx". For using the
> + dw_generic_filter(), slave drivers must pass exactly this string as
> + param to filter function.
> + - cfg_hi: Platform-specific initializer for the CFG_HI register
> + - cfg_lo: Platform-specific initializer for the CFG_LO register
> + - src_master: src master for transfers on allocated channel.
> + - dst_master: dest master for transfers on allocated channel.
>
> Example:
>
> @@ -14,4 +34,28 @@ Example:
> reg = <0xfc000000 0x1000>;
> interrupt-parent = <&vic1>;
> interrupts = <12>;
> +
> + nr_channels = <8>;
> + chan_allocation_order = <1>;
> + chan_priority = <1>;
> + block_size = <0xfff>;
> + nr_masters = <2>;
> + data_width = <3 3 0 0>;
> +
> + slave_info {
> + uart0-tx {
> + bus_id = "uart0-tx";
> + cfg_hi = <0x4000>; /* 0x8 << 11 */
> + cfg_lo = <0>;
> + src_master = <0>;
> + dst_master = <1>;
> + };
> + spi0-tx {
> + bus_id = "spi0-tx";
> + cfg_hi = <0x2000>; /* 0x4 << 11 */
> + cfg_lo = <0>;
> + src_master = <0>;
> + dst_master = <0>;
> + };
> + };
Why do you locate slave information under DMA controller node? From my
point of view the slave info belongs to corresponding device. For
example, above sections belong to UART0 and SPI0.
> };
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index c4b0eb3..9a7d084 100644
> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c
> @@ -1179,6 +1179,58 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
> dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
> }
>
> +bool dw_generic_filter(struct dma_chan *chan, void *param)
> +{
> + struct dw_dma *dw = to_dw_dma(chan->device);
> + static struct dw_dma *last_dw;
> + static char *last_bus_id;
> + int found = 0, i = -1;
> +
> + /*
> + * dmaengine framework calls this routine for all channels of all dma
> + * controller, until true is returned. If 'param' bus_id is not
> + * registered with a dma controller (dw), then there is no need of
> + * running below function for all channels of dw.
> + *
> + * This block of code does this by saving the parameters of last
> + * failure. If dw and param are same, i.e. trying on same dw with
> + * different channel, return false.
> + */
> + if (last_dw) {
> + if ((last_bus_id == param) && (last_dw == dw))
> + return false;
> + }
> +
> + /*
> + * Return true:
> + * - If dw_dma's platform data is not filled with slave info, then all
> + * dma controllers are fine for transfer.
> + * - Or if param is NULL
> + */
> + if (!dw->sd || !param)
> + return true;
> +
> + while (++i < dw->sd_count) {
> + if (!strcmp(dw->sd[i].bus_id, param)) {
> + found = 1;
> + break;
> + }
> + }
> +
> + if (!found) {
> + last_dw = dw;
> + last_bus_id = param;
> + return false;
Because of return here you could eliminate 'found' flag at all.
> + }
> +
> + chan->private = &dw->sd[i];
> + last_dw = NULL;
> + last_bus_id = NULL;
> +
> + return true;
> +}
> +EXPORT_SYMBOL(dw_generic_filter);
> +
> /* --------------------- Cyclic DMA API extensions -------------------- */
>
> /**
> @@ -1462,6 +1514,96 @@ static void dw_dma_off(struct dw_dma *dw)
> dw->chan[i].initialized = false;
> }
>
> +#ifdef CONFIG_OF
> +static struct dw_dma_platform_data *
> +__devinit dw_dma_parse_dt(struct platform_device *pdev)
> +{
> + struct device_node *sn, *cn, *np = pdev->dev.of_node;
> + struct dw_dma_platform_data *pdata;
> + struct dw_dma_slave *sd;
> + u32 count, val, arr[4];
> +
> + if (!np) {
> + dev_err(&pdev->dev, "Missing DT data\n");
> + return NULL;
> + }
> +
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return NULL;
> +
> + if (of_property_read_u32(np, "nr_channels", &pdata->nr_channels))
> + return NULL;
> +
> + if (of_property_read_bool(np, "is_private"))
> + pdata->is_private = true;
> +
> + if (!of_property_read_u32(np, "chan_allocation_order",
> + &val))
> + pdata->chan_allocation_order = (unsigned char)val;
> +
> + if (!of_property_read_u32(np, "chan_priority", &val))
> + pdata->chan_priority = (unsigned char)val;
> +
> + if (!of_property_read_u32(np, "block_size", &val))
> + pdata->block_size = (unsigned short)val;
> +
> + if (!of_property_read_u32(np, "nr_masters", &val)) {
> + if (val > 4)
> + return NULL;
> +
> + pdata->nr_masters = (unsigned char)val;
> + }
> +
> + if (!of_property_read_u32_array(np, "data_width", arr,
> + pdata->nr_masters))
> + for (count = 0; count < pdata->nr_masters; count++)
> + pdata->data_width[count] = arr[count];
> +
> + /* parse slave data */
> + sn = of_find_node_by_name(np, "slave_info");
> + if (!sn)
> + return pdata;
> +
> + count = 0;
> + /* calculate number of slaves */
> + for_each_child_of_node(sn, cn)
> + count++;
Is there any other way to get amount of children?
> +
> + if (!count)
> + return NULL;
> +
> + sd = devm_kzalloc(&pdev->dev, sizeof(*sd) * count, GFP_KERNEL);
> + if (!sd)
> + return NULL;
> +
> + count = 0;
> + for_each_child_of_node(sn, cn) {
> + of_property_read_string(cn, "bus_id", &sd[count].bus_id);
> + of_property_read_u32(cn, "cfg_hi", &sd[count].cfg_hi);
> + of_property_read_u32(cn, "cfg_lo", &sd[count].cfg_lo);
> + if (!of_property_read_u32(cn, "src_master", &val))
> + sd[count].src_master = (u8)val;
> +
> + if (!of_property_read_u32(cn, "dst_master", &val))
> + sd[count].dst_master = (u8)val;
> +
> + sd[count].dma_dev = &pdev->dev;
> + count++;
> + }
> +
> + pdata->sd = sd;
> + pdata->sd_count = count;
> +
> + return pdata;
Here you return NULL or valid pointer
> +}
> +#else
> +static inline int dw_dma_parse_dt(struct platform_device *pdev)
> +{
> + return -ENOSYS;
...here you return an error.
> +}
> +#endif
> +
> static int __devinit dw_probe(struct platform_device *pdev)
> {
> struct dw_dma_platform_data *pdata;
> @@ -1478,6 +1620,9 @@ static int __devinit dw_probe(struct platform_device *pdev)
> int i;
>
> pdata = dev_get_platdata(&pdev->dev);
> + if (!pdata)
> + pdata = dw_dma_parse_dt(pdev);
> +
> if (!pdata || pdata->nr_channels > DW_DMA_MAX_NR_CHANNELS)
...and here you didn't check for an error.
> return -EINVAL;
>
> @@ -1512,6 +1657,8 @@ static int __devinit dw_probe(struct platform_device *pdev)
> clk_prepare_enable(dw->clk);
>
> dw->regs = regs;
> + dw->sd = pdata->sd;
> + dw->sd_count = pdata->sd_count;
>
> /* get hardware configuration parameters */
> if (autocfg) {
> diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
> index ff39fa6..5cc61ba 100644
> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -231,6 +231,10 @@ struct dw_dma {
> struct tasklet_struct tasklet;
> struct clk *clk;
>
> + /* slave information */
> + struct dw_dma_slave *sd;
> + unsigned int sd_count;
> +
> u8 all_chan_mask;
>
> /* hardware configuration */
> diff --git a/include/linux/dw_dmac.h b/include/linux/dw_dmac.h
> index 62a6190..4d1c8c3 100644
> --- a/include/linux/dw_dmac.h
> +++ b/include/linux/dw_dmac.h
> @@ -15,6 +15,26 @@
> #include <linux/dmaengine.h>
>
> /**
> + * struct dw_dma_slave - Controller-specific information about a slave
> + *
> + * @dma_dev: required DMA master device. Depricated.
> + * @bus_id: name of this device channel, not just a device name since
> + * devices may have more than one channel e.g. "foo_tx"
> + * @cfg_hi: Platform-specific initializer for the CFG_HI register
> + * @cfg_lo: Platform-specific initializer for the CFG_LO register
> + * @src_master: src master for transfers on allocated channel.
> + * @dst_master: dest master for transfers on allocated channel.
> + */
> +struct dw_dma_slave {
> + struct device *dma_dev;
> + const char *bus_id;
> + u32 cfg_hi;
> + u32 cfg_lo;
> + u8 src_master;
> + u8 dst_master;
> +};
> +
> +/**
> * struct dw_dma_platform_data - Controller configuration parameters
> * @nr_channels: Number of channels supported by hardware (max 8)
> * @is_private: The device channels should be marked as private and not for
> @@ -25,6 +45,8 @@
> * @nr_masters: Number of AHB masters supported by the controller
> * @data_width: Maximum data width supported by hardware per AHB master
> * (0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
> + * @sd: slave specific data. Used for configuring channels
> + * @sd_count: count of slave data structures passed.
> */
> struct dw_dma_platform_data {
> unsigned int nr_channels;
> @@ -38,6 +60,9 @@ struct dw_dma_platform_data {
> unsigned short block_size;
> unsigned char nr_masters;
> unsigned char data_width[4];
> +
> + struct dw_dma_slave *sd;
> + unsigned int sd_count;
> };
>
> /* bursts size */
> @@ -52,23 +77,6 @@ enum dw_dma_msize {
> DW_DMA_MSIZE_256,
> };
>
> -/**
> - * struct dw_dma_slave - Controller-specific information about a slave
> - *
> - * @dma_dev: required DMA master device
> - * @cfg_hi: Platform-specific initializer for the CFG_HI register
> - * @cfg_lo: Platform-specific initializer for the CFG_LO register
> - * @src_master: src master for transfers on allocated channel.
> - * @dst_master: dest master for transfers on allocated channel.
> - */
> -struct dw_dma_slave {
> - struct device *dma_dev;
> - u32 cfg_hi;
> - u32 cfg_lo;
> - u8 src_master;
> - u8 dst_master;
> -};
> -
> /* Platform-configurable bits in CFG_HI */
> #define DWC_CFGH_FCMODE (1 << 0)
> #define DWC_CFGH_FIFO_MODE (1 << 1)
> @@ -106,5 +114,6 @@ void dw_dma_cyclic_stop(struct dma_chan *chan);
> dma_addr_t dw_dma_get_src_addr(struct dma_chan *chan);
>
> dma_addr_t dw_dma_get_dst_addr(struct dma_chan *chan);
> +bool dw_generic_filter(struct dma_chan *chan, void *param);
>
> #endif /* DW_DMAC_H */
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Joseph Lo @ 2012-10-12 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012075358.GA4962@S2101-09.ap.freescale.net>
On Fri, 2012-10-12 at 15:54 +0800, Shawn Guo wrote:
> On Thu, Oct 11, 2012 at 09:48:45AM -0700, Colin Cross wrote:
> > As is, coupled cpuidle will work on Tegra30, but it will unnecessarily
> > wake up the secondary cpus during the transitions to off and back on
> > again. Those cpus will immediately go back to single-cpu LP2,
>
> I'm sure coupled cpuidle will work like that. We have the following
> code at the end of cpuidle_enter_state_coupled() to wait until all
> coupled cpus have exited idle.
>
> while (!cpuidle_coupled_no_cpus_ready(coupled))
> cpu_relax();
>
> The cpu woken up during the transitions will just loop there until all
> other 3 cpus exit from idle function.
>
Did this a good idea if the CPU was been woken up from an interrupt but
it still needed to wait all other CPUs been woken up then it could
handle the interrupt?
Thanks,
Joseph
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Shawn Guo @ 2012-10-12 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350030264.15495.14.camel@jlo-ubuntu-64.nvidia.com>
On Fri, Oct 12, 2012 at 04:24:24PM +0800, Joseph Lo wrote:
> On Fri, 2012-10-12 at 15:54 +0800, Shawn Guo wrote:
> > On Thu, Oct 11, 2012 at 09:48:45AM -0700, Colin Cross wrote:
> > > As is, coupled cpuidle will work on Tegra30, but it will unnecessarily
> > > wake up the secondary cpus during the transitions to off and back on
> > > again. Those cpus will immediately go back to single-cpu LP2,
> >
> > I'm sure coupled cpuidle will work like that. We have the following
> > code at the end of cpuidle_enter_state_coupled() to wait until all
> > coupled cpus have exited idle.
> >
> > while (!cpuidle_coupled_no_cpus_ready(coupled))
> > cpu_relax();
> >
> > The cpu woken up during the transitions will just loop there until all
> > other 3 cpus exit from idle function.
> >
>
> Did this a good idea if the CPU was been woken up from an interrupt but
> it still needed to wait all other CPUs been woken up then it could
> handle the interrupt?
>
This is how coupled cpuidle gets implemented right now. And that's
why I see RCU stall warning reported on that cpu when I tried coupled
cpuidle on imx6q (CA9 Quad).
Shawn
^ permalink raw reply
* [PATCH 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Viresh Kumar @ 2012-10-12 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350030203.10584.139.camel@smile>
On 12 October 2012 13:53, Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> On Fri, 2012-10-12 at 11:14 +0530, Viresh Kumar wrote:
> My few comments are below.
Most welcome :)
>> diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
>> @@ -14,4 +34,28 @@ Example:
>> reg = <0xfc000000 0x1000>;
>> interrupt-parent = <&vic1>;
>> interrupts = <12>;
>> +
>> + nr_channels = <8>;
>> + chan_allocation_order = <1>;
>> + chan_priority = <1>;
>> + block_size = <0xfff>;
>> + nr_masters = <2>;
>> + data_width = <3 3 0 0>;
>> +
>> + slave_info {
>> + uart0-tx {
>> + bus_id = "uart0-tx";
>> + cfg_hi = <0x4000>; /* 0x8 << 11 */
>> + cfg_lo = <0>;
>> + src_master = <0>;
>> + dst_master = <1>;
>> + };
>> + spi0-tx {
>> + bus_id = "spi0-tx";
>> + cfg_hi = <0x2000>; /* 0x4 << 11 */
>> + cfg_lo = <0>;
>> + src_master = <0>;
>> + dst_master = <0>;
>> + };
>> + };
> Why do you locate slave information under DMA controller node? From my
> point of view the slave info belongs to corresponding device. For
> example, above sections belong to UART0 and SPI0.
Consider one spi driver is used on 5 different platforms with
different DMA controllers.
So, 5 DMA drivers and so 5 DMA platform_data. Wherever we add this node, this
data can't be processed by spi-driver, as we can't add DT processing routines
for all DMA drivers in spi.
The best place to process DT nodes is DW_DMAC driver, because it is
dw_dmac's data.
That's why i added them under DMA.
>> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
>> + while (++i < dw->sd_count) {
>> + if (!strcmp(dw->sd[i].bus_id, param)) {
>> + found = 1;
>> + break;
>> + }
>> + }
>> +
>> + if (!found) {
>> + last_dw = dw;
>> + last_bus_id = param;
>> + return false;
> Because of return here you could eliminate 'found' flag at all.
Yeah.
>> +static struct dw_dma_platform_data *
>> +__devinit dw_dma_parse_dt(struct platform_device *pdev)
>> +{
>> + for_each_child_of_node(sn, cn)
>> + count++;
> Is there any other way to get amount of children?
I tried my best to find one, referred to lots of drivers. And found
this way in most of the places. ex: drivers/pinctrl/***
>> + return pdata;
> Here you return NULL or valid pointer
>> +}
>> +#else
>> +static inline int dw_dma_parse_dt(struct platform_device *pdev)
>> +{
>> + return -ENOSYS;
> ...here you return an error.
Look at prototype of both versions of these routines. Its a bug. Thanks
for pointing out.
>> if (!pdata || pdata->nr_channels > DW_DMA_MAX_NR_CHANNELS)
> ...and here you didn't check for an error.
With above bug fixed, this will be automatically resolved as NULL is treated as
failure.
--
viresh
^ permalink raw reply
* [PATCH] pinctrl/nomadik: update other alternate-C functions on DB8500
From: Linus Walleij @ 2012-10-12 8:40 UTC (permalink / raw)
To: linux-arm-kernel
From: Jean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
In pinctrl-nomadik-db8500.c, add missing definitions that deal
with other alternate-C functions.
Signed-off-by: Jean-Nicolas Graux <jean-nicolas.graux@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-nomadik-db8500.c | 101 +++++++++++++++++++++++++++++--
1 file changed, 96 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-nomadik-db8500.c b/drivers/pinctrl/pinctrl-nomadik-db8500.c
index debaa75b..ef6f26d 100644
--- a/drivers/pinctrl/pinctrl-nomadik-db8500.c
+++ b/drivers/pinctrl/pinctrl-nomadik-db8500.c
@@ -600,14 +600,66 @@ static const unsigned usbsim_c_2_pins[] = { DB8500_PIN_AF8 };
static const unsigned i2c3_c_2_pins[] = { DB8500_PIN_AG7, DB8500_PIN_AF7 };
/* Other C1 column */
+static const unsigned u2rx_oc1_1_pins[] = { DB8500_PIN_AB2 };
+static const unsigned stmape_oc1_1_pins[] = { DB8500_PIN_AA4, DB8500_PIN_Y4,
+ DB8500_PIN_Y2, DB8500_PIN_AA2, DB8500_PIN_AA1 };
+static const unsigned remap0_oc1_1_pins[] = { DB8500_PIN_E1 };
+static const unsigned remap1_oc1_1_pins[] = { DB8500_PIN_E2 };
+static const unsigned ptma9_oc1_1_pins[] = { DB8500_PIN_G5, DB8500_PIN_G4,
+ DB8500_PIN_H4, DB8500_PIN_H3, DB8500_PIN_J3, DB8500_PIN_H2,
+ DB8500_PIN_J2, DB8500_PIN_H1 };
static const unsigned kp_oc1_1_pins[] = { DB8500_PIN_C6, DB8500_PIN_B3,
DB8500_PIN_C4, DB8500_PIN_E6, DB8500_PIN_A3, DB8500_PIN_B6,
DB8500_PIN_D6, DB8500_PIN_B7 };
+static const unsigned rf_oc1_1_pins[] = { DB8500_PIN_D8, DB8500_PIN_D9 };
+static const unsigned hxclk_oc1_1_pins[] = { DB8500_PIN_D16 };
+static const unsigned uartmodrx_oc1_1_pins[] = { DB8500_PIN_B17 };
+static const unsigned uartmodtx_oc1_1_pins[] = { DB8500_PIN_C16 };
+static const unsigned stmmod_oc1_1_pins[] = { DB8500_PIN_C19, DB8500_PIN_C17,
+ DB8500_PIN_A18, DB8500_PIN_C18, DB8500_PIN_B19 };
+static const unsigned hxgpio_oc1_1_pins[] = { DB8500_PIN_D21, DB8500_PIN_D20,
+ DB8500_PIN_C20, DB8500_PIN_B21, DB8500_PIN_C21, DB8500_PIN_A22,
+ DB8500_PIN_B24, DB8500_PIN_C22 };
+static const unsigned rf_oc1_2_pins[] = { DB8500_PIN_C23, DB8500_PIN_D23 };
static const unsigned spi2_oc1_1_pins[] = { DB8500_PIN_AH13, DB8500_PIN_AG12,
DB8500_PIN_AH12, DB8500_PIN_AH11 };
static const unsigned spi2_oc1_2_pins[] = { DB8500_PIN_AH13, DB8500_PIN_AH12,
DB8500_PIN_AH11 };
+/* Other C2 column */
+static const unsigned sbag_oc2_1_pins[] = { DB8500_PIN_AA4, DB8500_PIN_AB2,
+ DB8500_PIN_Y4, DB8500_PIN_Y2, DB8500_PIN_AA2, DB8500_PIN_AA1 };
+static const unsigned etmr4_oc2_1_pins[] = { DB8500_PIN_G5, DB8500_PIN_G4,
+ DB8500_PIN_H4, DB8500_PIN_H3, DB8500_PIN_J3, DB8500_PIN_H2,
+ DB8500_PIN_J2, DB8500_PIN_H1 };
+static const unsigned ptma9_oc2_1_pins[] = { DB8500_PIN_D17, DB8500_PIN_D16,
+ DB8500_PIN_B17, DB8500_PIN_C16, DB8500_PIN_C19, DB8500_PIN_C17,
+ DB8500_PIN_A18, DB8500_PIN_C18, DB8500_PIN_B19, DB8500_PIN_B20,
+ DB8500_PIN_D21, DB8500_PIN_D20, DB8500_PIN_C20, DB8500_PIN_B21,
+ DB8500_PIN_C21, DB8500_PIN_A22, DB8500_PIN_B24, DB8500_PIN_C22 };
+
+/* Other C3 column */
+static const unsigned stmmod_oc3_1_pins[] = { DB8500_PIN_AB2, DB8500_PIN_W2,
+ DB8500_PIN_W3, DB8500_PIN_V3, DB8500_PIN_V2 };
+static const unsigned stmmod_oc3_2_pins[] = { DB8500_PIN_G5, DB8500_PIN_G4,
+ DB8500_PIN_H4, DB8500_PIN_H3, DB8500_PIN_J3 };
+static const unsigned uartmodrx_oc3_1_pins[] = { DB8500_PIN_H2 };
+static const unsigned uartmodtx_oc3_1_pins[] = { DB8500_PIN_J2 };
+static const unsigned etmr4_oc3_1_pins[] = { DB8500_PIN_D17, DB8500_PIN_D16,
+ DB8500_PIN_B17, DB8500_PIN_C16, DB8500_PIN_C19, DB8500_PIN_C17,
+ DB8500_PIN_A18, DB8500_PIN_C18, DB8500_PIN_B19, DB8500_PIN_B20,
+ DB8500_PIN_D21, DB8500_PIN_D20, DB8500_PIN_C20, DB8500_PIN_B21,
+ DB8500_PIN_C21, DB8500_PIN_A22, DB8500_PIN_B24, DB8500_PIN_C22 };
+
+/* Other C4 column */
+static const unsigned sbag_oc4_1_pins[] = { DB8500_PIN_G5, DB8500_PIN_G4,
+ DB8500_PIN_H4, DB8500_PIN_H3, DB8500_PIN_J3, DB8500_PIN_H1 };
+static const unsigned hwobs_oc4_1_pins[] = { DB8500_PIN_D17, DB8500_PIN_D16,
+ DB8500_PIN_B17, DB8500_PIN_C16, DB8500_PIN_C19, DB8500_PIN_C17,
+ DB8500_PIN_A18, DB8500_PIN_C18, DB8500_PIN_B19, DB8500_PIN_B20,
+ DB8500_PIN_D21, DB8500_PIN_D20, DB8500_PIN_C20, DB8500_PIN_B21,
+ DB8500_PIN_C21, DB8500_PIN_A22, DB8500_PIN_B24, DB8500_PIN_C22 };
+
#define DB8500_PIN_GROUP(a,b) { .name = #a, .pins = a##_pins, \
.npins = ARRAY_SIZE(a##_pins), .altsetting = b }
@@ -726,9 +778,34 @@ static const struct nmk_pingroup nmk_db8500_groups[] = {
DB8500_PIN_GROUP(usbsim_c_2, NMK_GPIO_ALT_C),
DB8500_PIN_GROUP(i2c3_c_2, NMK_GPIO_ALT_C),
/* Other alt C1 column */
+ DB8500_PIN_GROUP(u2rx_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(stmape_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(remap0_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(remap1_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(ptma9_oc1_1, NMK_GPIO_ALT_C1),
DB8500_PIN_GROUP(kp_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(rf_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(hxclk_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(uartmodrx_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(uartmodtx_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(stmmod_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(hxgpio_oc1_1, NMK_GPIO_ALT_C1),
+ DB8500_PIN_GROUP(rf_oc1_2, NMK_GPIO_ALT_C1),
DB8500_PIN_GROUP(spi2_oc1_1, NMK_GPIO_ALT_C1),
DB8500_PIN_GROUP(spi2_oc1_2, NMK_GPIO_ALT_C1),
+ /* Other alt C2 column */
+ DB8500_PIN_GROUP(sbag_oc2_1, NMK_GPIO_ALT_C2),
+ DB8500_PIN_GROUP(etmr4_oc2_1, NMK_GPIO_ALT_C2),
+ DB8500_PIN_GROUP(ptma9_oc2_1, NMK_GPIO_ALT_C2),
+ /* Other alt C3 column */
+ DB8500_PIN_GROUP(stmmod_oc3_1, NMK_GPIO_ALT_C3),
+ DB8500_PIN_GROUP(stmmod_oc3_2, NMK_GPIO_ALT_C3),
+ DB8500_PIN_GROUP(uartmodrx_oc3_1, NMK_GPIO_ALT_C3),
+ DB8500_PIN_GROUP(uartmodtx_oc3_1, NMK_GPIO_ALT_C3),
+ DB8500_PIN_GROUP(etmr4_oc3_1, NMK_GPIO_ALT_C3),
+ /* Other alt C4 column */
+ DB8500_PIN_GROUP(sbag_oc4_1, NMK_GPIO_ALT_C4),
+ DB8500_PIN_GROUP(hwobs_oc4_1, NMK_GPIO_ALT_C4),
};
/* We use this macro to define the groups applicable to a function */
@@ -742,7 +819,7 @@ DB8500_FUNC_GROUPS(u1, "u1rxtx_a_1", "u1ctsrts_a_1");
* only available on two pins in alternative function C
*/
DB8500_FUNC_GROUPS(u2, "u2rxtx_b_1", "u2rxtx_c_1", "u2ctsrts_c_1",
- "u2rxtx_c_2", "u2rxtx_c_3");
+ "u2rxtx_c_2", "u2rxtx_c_3", "u2rx_oc1_1");
DB8500_FUNC_GROUPS(ipi2c, "ipi2c_a_1", "ipi2c_a_2");
/*
* MSP0 can only be on a certain set of pins, but the TX/RX pins can be
@@ -784,8 +861,10 @@ DB8500_FUNC_GROUPS(i2c2, "i2c2_b_1", "i2c2_b_2");
* so select one of each.
*/
DB8500_FUNC_GROUPS(uartmod, "uartmodtx_b_1", "uartmodrx_b_1", "uartmodrx_b_2",
- "uartmodrx_c_1", "uartmod_tx_c_1");
-DB8500_FUNC_GROUPS(stmmod, "stmmod_b_1", "stmmod_c_1");
+ "uartmodrx_c_1", "uartmod_tx_c_1", "uartmodrx_oc1_1",
+ "uartmodtx_oc1_1", "uartmodrx_oc3_1", "uartmodtx_oc3_1");
+DB8500_FUNC_GROUPS(stmmod, "stmmod_b_1", "stmmod_c_1", "stmmod_oc1_1",
+ "stmmod_oc3_1", "stmmod_oc3_2");
DB8500_FUNC_GROUPS(spi3, "spi3_b_1");
/* Select between CS0 on alt B or PS1 on alt C */
DB8500_FUNC_GROUPS(sm, "sm_b_1", "smcs0_b_1", "smcs1_b_1", "smcleale_c_1",
@@ -799,13 +878,19 @@ DB8500_FUNC_GROUPS(ipjtag, "ipjtag_c_1");
DB8500_FUNC_GROUPS(slim0, "slim0_c_1");
DB8500_FUNC_GROUPS(ms, "ms_c_1");
DB8500_FUNC_GROUPS(iptrigout, "iptrigout_c_1");
-DB8500_FUNC_GROUPS(stmape, "stmape_c_1", "stmape_c_2");
+DB8500_FUNC_GROUPS(stmape, "stmape_c_1", "stmape_c_2", "stmape_oc1_1");
DB8500_FUNC_GROUPS(mc5, "mc5_c_1");
DB8500_FUNC_GROUPS(usbsim, "usbsim_c_1", "usbsim_c_2");
DB8500_FUNC_GROUPS(i2c3, "i2c3_c_1", "i2c3_c_2");
DB8500_FUNC_GROUPS(spi0, "spi0_c_1");
DB8500_FUNC_GROUPS(spi2, "spi2_oc1_1", "spi2_oc1_2");
-
+DB8500_FUNC_GROUPS(remap, "remap0_oc1_1", "remap1_oc1_1");
+DB8500_FUNC_GROUPS(sbag, "sbag_oc2_1", "sbag_oc4_1");
+DB8500_FUNC_GROUPS(ptm, "ptma9_oc1_1", "ptma9_oc2_1");
+DB8500_FUNC_GROUPS(rf, "rf_oc1_1", "rf_oc1_2");
+DB8500_FUNC_GROUPS(hx, "hxclk_oc1_1", "hxgpio_oc1_1");
+DB8500_FUNC_GROUPS(etm, "etmr4_oc2_1", "etmr4_oc3_1");
+DB8500_FUNC_GROUPS(hwobs, "hwobs_oc4_1");
#define FUNCTION(fname) \
{ \
.name = #fname, \
@@ -858,6 +943,12 @@ static const struct nmk_function nmk_db8500_functions[] = {
FUNCTION(i2c3),
FUNCTION(spi0),
FUNCTION(spi2),
+ FUNCTION(remap),
+ FUNCTION(ptm),
+ FUNCTION(rf),
+ FUNCTION(hx),
+ FUNCTION(etm),
+ FUNCTION(hwobs),
};
static const struct prcm_gpiocr_altcx_pin_desc db8500_altcx_pins[] = {
--
1.7.11.3
^ permalink raw reply related
* [PATCH] i2c: change the id to let the i2c device work
From: Bo Shen @ 2012-10-12 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121012082155.GP11726@opensource.wolfsonmicro.com>
On 10/12/2012 16:21, Mark Brown wrote:
> On Fri, Oct 12, 2012 at 10:05:21AM +0200, Jean Delvare wrote:
>
>> Ah sorry I misread Mark's request. i2c-gpio will turn the platform
>> device ID into bus number, it can indeed not be forced through platform
>> data. But I don't think any other i2c bus driver allows this either. I
>> don't quite see the problem with setting a platform device ID even if
>> there's only one instance of the platform device. I have many examples
>> of this on my machine:
>> Fixed MDIO bus.0
>> coretemp.0
>> vesafb.0
>
> This is generally bad style; if it's required by APIs we really should
> be fixing the APIs to remove this sort of dependency. Aside from the
> ugliness it tends to be fragile.
>
>> So please just set the platform device ID to 0 (or whatever i2c adapter
>> number you want) and your problem is solved. As you just proposed
>> initially, actually :)
>
> Though it *does* need a comprehensible commit message so people can
> understand what on earth the change is intended to do.
I will update the commit message and send v2 patch.
Thanks
BR,
Bo Shen
^ permalink raw reply
* alignment faults in 3.6
From: Russell King - ARM Linux @ 2012-10-12 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201210120811.43290.arnd@arndb.de>
On Fri, Oct 12, 2012 at 08:11:42AM +0000, Arnd Bergmann wrote:
> On Thursday 11 October 2012, M?ns Rullg?rd wrote:
> > > But, the IP header is expected to be aligned.
> >
> > Everything tells the compiler the struct is perfectly aligned. When the
> > buggy driver passes a misaligned pointer, bad things happen.
>
> Would it be appropriate to add a WARN_ON_ONCE() in the alignment fault path
> then? If all alignment faults in the kernel are caused by broken drivers,
> that would at least give us some hope of finding those drivers while at the
> same time not causing much overhead in the case where we need to do the
> fixup in the meantime.
No. It is my understanding that various IP option processing can also
cause the alignment fault handler to be invoked, even when the packet is
properly aligned, and then there's jffs2/mtd which also relies upon
alignment faults being fixed up.
^ permalink raw reply
* [PATCH 2/2] ARM: unwind: enable dumping stacks for SMP && ARM_UNWIND
From: Russell King - ARM Linux @ 2012-10-12 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1346021216-21979-3-git-send-email-ccross@android.com>
On Sun, Aug 26, 2012 at 03:46:56PM -0700, Colin Cross wrote:
> Unwinding with CONFIG_ARM_UNWIND is much more complicated than
> unwinding with CONFIG_FRAME_POINTER, but there are only a few points
> that require validation in order to avoid faults or infinite loops.
> Avoiding faults is easy by adding checks to verify that all accesses
> relative to the frame's stack pointer remain inside the stack.
>
> When CONFIG_FRAME_POINTER is not set it is possible for two frames to
> have the same SP, so there is no way to avoid repeated calls to
> unwind_frame continuing forever.
So here you admit that this patch can cause the unwinder to loop forever,
which would provide no way out of that. Why do you think this patch is
suitable for mainline with such a problem?
^ permalink raw reply
* [PATCH 1/4] usb: phy: add a new driver for usb3 phy
From: kishon @ 2012-10-12 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011005944.GX12552@atomide.com>
Hi Tony,
On Thursday 11 October 2012 06:29 AM, Tony Lindgren wrote:
> Hi,
>
> * Kishon Vijay Abraham I <kishon@ti.com> [120919 04:32]:
>> Added a driver for usb3 phy that handles the interaction between usb phy
>> device and dwc3 controller.
>>
>> This also includes device tree support for usb3 phy driver and
>> the documentation with device tree binding information is updated.
>>
>> Currently writing to control module register is taken care in this
>> driver which will be removed once the control module driver is in place.
>
> You may be able to set up the control module register with one
> of the following Linux standard frameworks:
>
> 1. Fixed regulator defined in mach-omap2/control.c
Is it control.c?
>
> In this case the PHY driver can pick up the regulator by name.
Do you mean we have to define something like fixed_voltage_config
defined in board-4430sdp.c?
From whatever I could make out from regulator/fixed.c,
enabling/disabling of regulator is done using only gpio. I'm not sure
how we can use that to write to control module register.
>
> 2. A mux mapped with pinctrl framework using pinctrl-single,bits
> binding
>
> And in this case the PHY driver can request the named pinctrl
> states like "enabled" and "disabled".
>
>> --- a/Documentation/devicetree/bindings/usb/usb-phy.txt
>> +++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
>> @@ -15,3 +15,21 @@ usb2phy at 4a0ad080 {
>> reg = <0x4a0ad080 0x58>,
>> <0x4a002300 0x4>;
>> };
>
> The comments also apply to the omap_usb2.c driver for
> 0x4a002300 above.
>
>> +
>> +OMAP USB3 PHY
>> +
>> +Required properties:
>> + - compatible: Should be "ti,omap-usb3"
>> + - reg : Address and length of the register set for the device. Also
>> +add the address of control module phy power register until a driver for
>> +control module is added
>> +
>> +This is usually a subnode of ocp2scp to which it is connected.
>> +
>> +usb3phy at 4a084400 {
>> + compatible = "ti,omap-usb3";
>> + reg = <0x0x4a084400 0x80>,
>> + <0x4a084800 0x64>,
>> + <0x4a084c00 0x40>,
>> + <0x4a002370 0x4>;
>> +};
>
> And register 0x4a002370 here. Care to post some info what the
> 0x4a002370 register bits do? Is that same as CONTROL_DEV_CONF
> on omap4, or does it have other bits there too?
It's CONTROL_PHY_POWER_USB register and it's structure looks like this.
31:22 USB_PWRCTL_CLK_FREQ
21:14 USB_PWRCTL_CLK_CMD
13:0 RESERVED
CLK_CMD takes values to power up/down the TX and RX in various combinations.
And CLK_FREQ takes values for clock configuration.
Thanks
Kishon
^ permalink raw reply
* [RESEND PATCH 1/2] mmc: mmci: Fix incorrect handling of HW flow control for SDIO
From: Russell King - ARM Linux @ 2012-10-12 9:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349885000-22887-1-git-send-email-ulf.hansson@stericsson.com>
On Wed, Oct 10, 2012 at 06:03:19PM +0200, Ulf Hansson wrote:
> From: Ulf Hansson <ulf.hansson@linaro.org>
>
> For data writes <= 8 bytes, HW flow control was disabled but
> never re-enabled when the transfer was completed. This meant
> that a following read request would give buffer overrun errors.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Both look fine to me too. Linus' has already said what needs to happen
with these two. Thanks.
^ permalink raw reply
* [PATCH v2 5/8] clk: don't mark clkdev_add_table as init
From: Russell King - ARM Linux @ 2012-10-12 9:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349813638-4617-6-git-send-email-arnd@arndb.de>
On Tue, Oct 09, 2012 at 10:13:55PM +0200, Arnd Bergmann wrote:
> s3c2440_clk_add is a subsys_interface method and calls clkdev_add_table,
> which means we might be calling it after the __init section is
> discarded.
>
> Without this patch, building mini2440_defconfig results in:
>
> WARNING: vmlinux.o(.text+0x9848): Section mismatch in reference from the function s3c2440_clk_add() to the function .init.text:clkdev_add_table()
> The function s3c2440_clk_add() references
> the function __init clkdev_add_table().
> This is often because s3c2440_clk_add lacks a __init
> annotation or the annotation of clkdev_add_table is wrong.
I'm not sure this is the right thing to do. I suspect this comes from the
stupidly complex samsung code, and that this is actually safe - I suspect
that s3c2440_clk_add() needs to be appropriately marked, but then you end
up having to trace its call path through various structures etc.
^ permalink raw reply
* [RFC PATCH v2 08/16] ARM: omap: add hsmmc am33xx specific init
From: Hebbar, Gururaja @ 2012-10-12 9:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349982281-10785-9-git-send-email-mporter@ti.com>
Matt
On Fri, Oct 12, 2012 at 00:34:33, Porter, Matt wrote:
> AM33xx requires special handling in hsmmc initialization
> platform glue.
Since AM335x boots mainly through DT, do we still need this patch.
This function will be called in case of initializing hsmmc with
Platform data.
>
> Signed-off-by: Matt Porter <mporter@ti.com>
> ---
> arch/arm/mach-omap2/hsmmc.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
..snip..
..snip..
> name = "omap_hsmmc";
> res = snprintf(oh_name, MAX_OMAP_MMC_HWMOD_NAME_LEN,
> --
> 1.7.9.5
>
> _______________________________________________
> Davinci-linux-open-source mailing list
> Davinci-linux-open-source at linux.davincidsp.com
> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
>
Regards,
Gururaja
^ permalink raw reply
* [GIT PULL] Versatile Express clk
From: Pawel Moll @ 2012-10-12 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011224017.2941.11303@nucleus>
On Thu, 2012-10-11 at 23:40 +0100, Mike Turquette wrote:
> > Would you be so kind and pull the VE clocking stuff? They are rebased on
> > top of Linus' Realview patch.
>
> I've taken these into my new clk-next towards 3.8. That branch is not
> yet pushed out publicly but will be after -rc1 is released.
Awesome, thanks!
Pawe?
^ permalink raw reply
* [PATCH 1/1] pinctrl/at91: fix compatible order
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-12 9:23 UTC (permalink / raw)
To: linux-arm-kernel
the sam9x5 is new version of the rm9200 not the invert
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
---
drivers/pinctrl/pinctrl-at91.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
index 9c0fe11..bdb152b 100644
--- a/drivers/pinctrl/pinctrl-at91.c
+++ b/drivers/pinctrl/pinctrl-at91.c
@@ -1331,8 +1331,8 @@ static void __devinit at91_gpio_probe_fixup(void)
}
static struct of_device_id at91_gpio_of_match[] __devinitdata = {
- { .compatible = "atmel,at91rm9200-gpio", .data = &at91rm9200_ops },
{ .compatible = "atmel,at91sam9x5-gpio", .data = &at91sam9x5_ops, },
+ { .compatible = "atmel,at91rm9200-gpio", .data = &at91rm9200_ops },
{ /* sentinel */ }
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Andy Shevchenko @ 2012-10-12 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKohpon4FZdPXFOXvVqExY=xrwozELYvNbE3_zHoRw2O0nszhw@mail.gmail.com>
On Fri, Oct 12, 2012 at 11:34 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 12 October 2012 13:53, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
>> On Fri, 2012-10-12 at 11:14 +0530, Viresh Kumar wrote:
>>> diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
>>> @@ -14,4 +34,28 @@ Example:
>>> reg = <0xfc000000 0x1000>;
>>> interrupt-parent = <&vic1>;
>>> interrupts = <12>;
>>> +
>>> + nr_channels = <8>;
>>> + chan_allocation_order = <1>;
>>> + chan_priority = <1>;
>>> + block_size = <0xfff>;
>>> + nr_masters = <2>;
>>> + data_width = <3 3 0 0>;
>>> +
>>> + slave_info {
>>> + uart0-tx {
>>> + bus_id = "uart0-tx";
>>> + cfg_hi = <0x4000>; /* 0x8 << 11 */
>>> + cfg_lo = <0>;
>>> + src_master = <0>;
>>> + dst_master = <1>;
>>> + };
>>> + spi0-tx {
>>> + bus_id = "spi0-tx";
>>> + cfg_hi = <0x2000>; /* 0x4 << 11 */
>>> + cfg_lo = <0>;
>>> + src_master = <0>;
>>> + dst_master = <0>;
>>> + };
>>> + };
>> Why do you locate slave information under DMA controller node? From my
>> point of view the slave info belongs to corresponding device. For
>> example, above sections belong to UART0 and SPI0.
>
> Consider one spi driver is used on 5 different platforms with
> different DMA controllers.
> So, 5 DMA drivers and so 5 DMA platform_data. Wherever we add this node, this
> data can't be processed by spi-driver, as we can't add DT processing routines
> for all DMA drivers in spi.
>
> The best place to process DT nodes is DW_DMAC driver, because it is
> dw_dmac's data.
> That's why i added them under DMA.
Fair enough.
>>> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
>>> +static struct dw_dma_platform_data *
>>> +__devinit dw_dma_parse_dt(struct platform_device *pdev)
>>> +{
>
>>> + for_each_child_of_node(sn, cn)
>>> + count++;
>> Is there any other way to get amount of children?
>
> I tried my best to find one, referred to lots of drivers. And found
> this way in most of the places. ex: drivers/pinctrl/***
I understand your way of allocating memory, but what about using
linked list instead of array?
And one more thing. May be we could introduce backlink to the platform
data in the dw_dma structure instead of copying certain parameters?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH 2/3] dmaengine: dw_dmac: Enhance device tree support
From: Viresh Kumar @ 2012-10-12 9:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Ve9uETO0Wx=bNbPxjOxO_MoE_bkFCHtwBZAA6+7m8fdMw@mail.gmail.com>
On 12 October 2012 14:55, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> I understand your way of allocating memory, but what about using
> linked list instead of array?
I gave it a thought. Overhead was 4 bytes more per slave structure +
more cycles in filter routine (arrays are more faster :) ).
Because the DT capture is a one time activity, its better to save time
in filter fns.
> And one more thing. May be we could introduce backlink to the platform
> data in the dw_dma structure instead of copying certain parameters?
Will do that in a separate patch, outside the scope of this patchset. :)
--
viresh
^ permalink raw reply
* [PATCH] Boottime: A tool for automatic measurement of kernel/bootloader boot time
From: Lee Jones @ 2012-10-12 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011201735.GA15313@kahuna>
On Thu, 11 Oct 2012, Nishanth Menon wrote:
> On 15:42-20121011, Lee Jones wrote:
> > From: Jonas Aaberg <jonas.aberg@stericsson.com>
> >
> > The overhead is very low and the results will be found under
> > sysfs/bootime, as well as detailed results in debugfs under
> > boottime/. The bootgraph* files are compatible with
> > scripts/bootgraph.pl. The reason for this patch is to provide
> > data (sysfs/boottime) suitable for automatic testcases as
> > well as help for developers to reduce the boot time (debugfs).
> Tried master:
> 250d8 Merge branch 'i2c-embedded/for-next' of git://git.pengutronix.de/git/wsa/linux
> and v3.6-rc7
> with omap2plus_defconfig + CONFIG_BOOTTIME enabled:
>
> init/boottime.c:47:9: error: ?cpu_usage_stat? defined as wrong kind of tag
> init/boottime.c:47:24: error: array type has incomplete element type
> init/boottime.c: In function ?boottime_mark_core?:
> init/boottime.c:127:313: error: ?struct kernel_stat? has no member named ?cpustat?
> init/boottime.c:128:311: error: ?struct kernel_stat? has no member named ?cpustat?
> init/boottime.c:129:313: error: ?struct kernel_stat? has no member named ?cpustat?
> init/boottime.c:130:310: error: ?struct kernel_stat? has no member named ?cpustat?
>
> if it depended on some other patch or a specific maintainer branch,
> it was'nt clear.
No, this is completely my fault.
There are added dependencies and fixups that I missed.
I'll fixup and resubmit.
Unfortunately, there are now other authors involved, so I need to
seek permission before squashing them in. Please bear with me.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] ARM: nomadik: fixup some FSMC merge problems
From: Jean-Christophe PLAGNIOL-VILLARD @ 2012-10-12 9:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349994182-26116-1-git-send-email-linus.walleij@linaro.org>
On 00:23 Fri 12 Oct , Linus Walleij wrote:
>
> Due to a clash between refactoring and due to loss of a header
> file that remained in my working tree the Nomadik stopped
> compiling after switching to the FSMC driver. This patch fixes
> it up.
>
> Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Best Regards,
J.
> ---
> arch/arm/mach-nomadik/board-nhk8815.c | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-nomadik/board-nhk8815.c b/arch/arm/mach-nomadik/board-nhk8815.c
> index a105d1b..3f97ef4 100644
> --- a/arch/arm/mach-nomadik/board-nhk8815.c
> +++ b/arch/arm/mach-nomadik/board-nhk8815.c
> @@ -37,14 +37,15 @@
> #include <plat/mtu.h>
> #include <plat/pincfg.h>
>
> -#include <mach/fsmc.h>
> -
> #include "cpu-8815.h"
>
> /* Initial value for SRC control register: all timers use MXTAL/8 source */
> #define SRC_CR_INIT_MASK 0x00007fff
> #define SRC_CR_INIT_VAL 0x2aaa8000
>
> +#define ALE_OFF 0x1000000
> +#define CLE_OFF 0x800000
> +
> /* These addresses span 16MB, so use three individual pages */
> static struct resource nhk8815_nand_resources[] = {
> {
> @@ -53,6 +54,16 @@ static struct resource nhk8815_nand_resources[] = {
> .end = 0x40000000 + SZ_16K - 1,
> .flags = IORESOURCE_MEM,
> }, {
> + .name = "nand_addr",
> + .start = 0x40000000 + ALE_OFF,
> + .end = 0x40000000 +ALE_OFF + SZ_16K - 1,
> + .flags = IORESOURCE_MEM,
> + }, {
> + .name = "nand_cmd",
> + .start = 0x40000000 + CLE_OFF,
> + .end = 0x40000000 + CLE_OFF + SZ_16K - 1,
> + .flags = IORESOURCE_MEM,
> + }, {
> .name = "fsmc_regs",
> .start = NOMADIK_FSMC_BASE,
> .end = NOMADIK_FSMC_BASE + SZ_4K - 1,
> @@ -105,8 +116,6 @@ static struct fsmc_nand_platform_data nhk8815_nand_platform_data = {
> .partitions = nhk8815_partitions,
> .nr_partitions = ARRAY_SIZE(nhk8815_partitions),
> .width = FSMC_NAND_BW8,
> - .ale_off = 0x1000000,
> - .cle_off = 0x800000,
> };
>
> static struct platform_device nhk8815_nand_device = {
> @@ -171,6 +180,10 @@ static struct platform_device nhk8815_onenand_device = {
> .num_resources = ARRAY_SIZE(nhk8815_onenand_resource),
> };
>
> +/* bus control reg. and bus timing reg. for CS0..CS3 */
> +#define FSMC_BCR(x) (NOMADIK_FSMC_VA + (x << 3))
> +#define FSMC_BTR(x) (NOMADIK_FSMC_VA + (x << 3) + 0x04)
> +
> static void __init nhk8815_onenand_init(void)
> {
> #ifdef CONFIG_MTD_ONENAND
> --
> 1.7.11.4
>
^ permalink raw reply
* [PATCH v2] i2c: change the id to let the i2c-gpio work
From: Bo Shen @ 2012-10-12 9:42 UTC (permalink / raw)
To: linux-arm-kernel
The i2c-gpio driver will turn the platform device ID to busnum.
When using platfrom device ID as -1, it means dynamically assigned
the busnum. When writing code, we need to make sure the busnum,
and call i2c_register_board_info(int busnum, ...) to register device
if using -1, we do not know the value of busnum.
In order to solve this issue, set the platform device ID as a fix number
Here using 0 to match the busnum used in i2c_regsiter_board_info().
Signed-off-by: Bo Shen <voice.shen@atmel.com>
---
Change since v1
Make the commit message more clear
---
arch/arm/mach-at91/at91sam9260_devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c
index 0f24cfb..805ef95 100644
--- a/arch/arm/mach-at91/at91sam9260_devices.c
+++ b/arch/arm/mach-at91/at91sam9260_devices.c
@@ -389,7 +389,7 @@ static struct i2c_gpio_platform_data pdata = {
static struct platform_device at91sam9260_twi_device = {
.name = "i2c-gpio",
- .id = -1,
+ .id = 0,
.dev.platform_data = &pdata,
};
--
1.7.9.5
^ permalink raw reply related
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