Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v5 07/14] dmaengine: add dma_request_slave_channel_compat()
From: Matt Porter @ 2013-01-30  6:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201301232228.46716.arnd@arndb.de>

On Wed, Jan 23, 2013 at 10:28:46PM +0000, Arnd Bergmann wrote:
> On Tuesday 15 January 2013, Matt Porter wrote:
> > Adds a dma_request_slave_channel_compat() wrapper which accepts
> > both the arguments from dma_request_channel() and
> > dma_request_slave_channel(). Based on whether the driver is
> > instantiated via DT, the appropriate channel request call will be
> > made.
> > 
> > This allows for a much cleaner migration of drivers to the
> > dmaengine DT API as platforms continue to be mixed between those
> > that boot using DT and those that do not.
> 
> I noticed today some drivers in linux-next that rely on this patch,
> but the patch itself still missing from -next.
> 
> > --- a/include/linux/dmaengine.h
> > +++ b/include/linux/dmaengine.h
> > @@ -1047,6 +1047,16 @@ void dma_run_dependencies(struct dma_async_tx_descriptor *tx);
> >  struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
> >  struct dma_chan *net_dma_find_channel(void);
> >  #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> > +static inline struct dma_chan
> > +*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
> > +                                 void *fn_param, struct device *dev,
> > +                                 char *name)
> > +{
> > +       if (dev->of_node)
> > +               return dma_request_slave_channel(dev, name);
> > +       else
> > +               return dma_request_channel(mask, fn, fn_param);
> > +}
> 
> Hmm, dma_request_channel is actually a macro that passes mask by reference,
> presumably because it can get modified by the filter function. Also, there
> may be cases where we do have an of_node but don't use the dma binding
> yet, or where dma_request_slave_channel doesn't actually use DT information
> but rather one of the other methods that Vinod was talking about adding.
> 
> I think what it should look like instead is the below.

Yes, looks correct now, thanks. I've incorporated it into v6.

-Matt

> 
> 	Arnd
> 
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index bfcdecb..b6ffd7d 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -993,6 +993,19 @@ static inline void dma_release_channel(struct dma_chan *chan)
>  }
>  #endif
>  
> +static inline struct dma_chan *__dma_request_slave_channel_compat(dma_cap_mask_t *mask,
> +				dma_filter_fn fn, void *fn_param, struct device *dev,
> +				 char *name)
> +{
> +	struct dma_chan *chan;
> +
> +	chan = dma_request_slave_channel(dev, name);
> +	if (chan)
> +		return chan;
> +
> +	return __dma_request_channel(mask, fn, fn_param);
> +}
> +
>  /* --- DMA device --- */
>  
>  int dma_async_device_register(struct dma_device *device);
> @@ -1001,6 +1014,8 @@ void dma_run_dependencies(struct dma_async_tx_descriptor *tx);
>  struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
>  struct dma_chan *net_dma_find_channel(void);
>  #define dma_request_channel(mask, x, y) __dma_request_channel(&(mask), x, y)
> +#define dma_request_slave_channel_compat(mask, x, y, dev, name) \
> +	 __dma_request_slave_channel_compat(&(mask), x, y, dev, name)
>  
>  /* --- Helper iov-locking functions --- */
>  
> _______________________________________________
> 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] ARM: dts: remove generated .dtb files on clean
From: Santosh Shilimkar @ 2013-01-30  6:29 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1358890049-26981-1-git-send-email-nm@ti.com>

Looping RMK, Arnd

On Wednesday 23 January 2013 02:57 AM, Nishanth Menon wrote:
> commit 5f300acd8ae9f3d4585154370012ffc5c665330f
> (ARM: 7152/1: distclean: Remove generated .dtb files)
> ensured that dtbs were cleaned up when they were in
> arch/arm/boot.
> However, with the following commit:
> commit 499cd8298628eeabf0eb5eb6525d4faa0eec80d8
> (ARM: dt: change .dtb build rules to build in dts directory)
>
> make clean now leaves dtbs in arch/arm/boot/dts/
> untouched. Include dts directory so that clean-files rule
> from arch/arm/boot/dts/Makefile is invoked when make
> clean is done.
>
> Cc: Dirk Behme <dirk.behme@de.bosch.com>
> CC: Grant Likely <grant.likely@secretlab.ca>
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
>   arch/arm/boot/Makefile |    2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile
> index abfce28..3837f97 100644
> --- a/arch/arm/boot/Makefile
> +++ b/arch/arm/boot/Makefile
> @@ -115,4 +115,4 @@ i:
>   	$(CONFIG_SHELL) $(srctree)/$(src)/install.sh $(KERNELRELEASE) \
>   	$(obj)/Image System.map "$(INSTALL_PATH)"
>
> -subdir-	    := bootp compressed
> +subdir-	    := bootp compressed dts
>
Seems to be the valid fix for me.

Regards,
Santosh

^ permalink raw reply

* [PATCH] arm: dts: omap4-sdp: Add I2c pinctrl data
From: Luciano Coelho @ 2013-01-30  6:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1359371865-27907-1-git-send-email-sourav.poddar@ti.com>

Hi Sourav,

On Mon, 2013-01-28 at 16:47 +0530, Sourav Poddar wrote:
> Booting 3.8-rc4 om omap 4430sdp results in the following error
> 
> omap_i2c 48070000.i2c: did not get pins for i2c error: -19
> [    1.024261] omap_i2c 48070000.i2c: bus 0 rev0.12 at 100 kHz
> [    1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
> [    1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
> [    1.043762] omap_i2c 48060000.i2c: did not get pins for i2c error: -19
> [    1.050964] omap_i2c 48060000.i2c: bus 2 rev0.12 at 100 kHz
> [    1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
> [    1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
> 
> This happens because omap4 dts file is not adapted to use i2c through pinctrl
> framework. Populating i2c pinctrl data to get rid of the error.
> 
> Tested on omap4430 sdp with 3.8-rc4 kernel.
> 
> Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
> Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---

Could you do the same thing for panda? I'm getting the same kind of
errors with it:

[    0.000000] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 PandaBoard               
[...]
[    2.884826] omap_i2c 48072000.i2c: did not get pins for i2c error: -19                               
[    2.890686] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz                                          
[    2.892028] omap_i2c 48060000.i2c: did not get pins for i2c error: -19                               
[    2.899047] omap_i2c 48060000.i2c: bus 2 rev0.11 at 100 kHz                                          
[    2.906677] omap_i2c 48350000.i2c: did not get pins for i2c error: -19                               
[    2.912872] omap_i2c 48350000.i2c: bus 3 rev0.11 at 400 kHz                                          

--
Cheers,
Luca.

^ permalink raw reply

* [RESEND PATCH v5 3/7] usb: chipidea: add otg id switch and vbus connect/disconnect detect
From: kishon @ 2013-01-30  6:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1358733418-17969-4-git-send-email-peter.chen@freescale.com>

Hi,

On Monday 21 January 2013 07:26 AM, Peter Chen wrote:
> The main design flow is the same with msm otg driver, that is the id and
> vbus interrupt are handled at core driver, others are handled by
> individual drivers.
>
> - At former design, when switch usb role from device->host, it will call
> udc_stop, it will remove the gadget driver, so when switch role
> from host->device, it can't add gadget driver any more.
> At new design, when role switch occurs, the gadget just calls
> usb_gadget_vbus_disconnect/usb_gadget_vbus_connect as well as
> reset controller, it will not free any device/gadget structure
>
> - Add vbus connect and disconnect to core interrupt handler, it can
> notify udc driver by calling usb_gadget_vbus_disconnect
> /usb_gadget_vbus_connect.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
>   drivers/usb/chipidea/bits.h |   10 +++
>   drivers/usb/chipidea/ci.h   |    8 ++-
>   drivers/usb/chipidea/core.c |  177 ++++++++++++++++++++++++++++++++++++++----
>   drivers/usb/chipidea/otg.c  |   28 +++++---
>   drivers/usb/chipidea/otg.h  |    3 +
>   drivers/usb/chipidea/udc.c  |    2 +
>   6 files changed, 200 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
> index 050de85..ba9c6ef 100644
> --- a/drivers/usb/chipidea/bits.h
> +++ b/drivers/usb/chipidea/bits.h
> @@ -65,11 +65,21 @@
>   #define OTGSC_ASVIS	      BIT(18)
>   #define OTGSC_BSVIS	      BIT(19)
>   #define OTGSC_BSEIS	      BIT(20)
> +#define OTGSC_1MSIS	      BIT(21)
> +#define OTGSC_DPIS	      BIT(22)
>   #define OTGSC_IDIE	      BIT(24)
>   #define OTGSC_AVVIE	      BIT(25)
>   #define OTGSC_ASVIE	      BIT(26)
>   #define OTGSC_BSVIE	      BIT(27)
>   #define OTGSC_BSEIE	      BIT(28)
> +#define OTGSC_1MSIE	      BIT(29)
> +#define OTGSC_DPIE	      BIT(30)
> +#define OTGSC_INT_EN_BITS	(OTGSC_IDIE | OTGSC_AVVIE | OTGSC_ASVIE \
> +				| OTGSC_BSVIE | OTGSC_BSEIE | OTGSC_1MSIE \
> +				| OTGSC_DPIE)
> +#define OTGSC_INT_STATUS_BITS	(OTGSC_IDIS | OTGSC_AVVIS | OTGSC_ASVIS	\
> +				| OTGSC_BSVIS | OTGSC_BSEIS | OTGSC_1MSIS \
> +				| OTGSC_DPIS)
>
>   /* USBMODE */
>   #define USBMODE_CM            (0x03UL <<  0)
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 8702871..325d790 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -130,6 +130,7 @@ struct hw_bank {
>    * @transceiver: pointer to USB PHY, if any
>    * @hcd: pointer to usb_hcd for ehci host driver
>    * @otg: for otg support
> + * @events: events for otg, and handled at ci_role_work
>    */
>   struct ci13xxx {
>   	struct device			*dev;
> @@ -140,6 +141,7 @@ struct ci13xxx {
>   	enum ci_role			role;
>   	bool				is_otg;
>   	struct work_struct		work;
> +	struct delayed_work		dwork;
>   	struct workqueue_struct		*wq;
>
>   	struct dma_pool			*qh_pool;
> @@ -165,7 +167,9 @@ struct ci13xxx {
>   	bool				global_phy;
>   	struct usb_phy			*transceiver;
>   	struct usb_hcd			*hcd;
> -	struct usb_otg      otg;
> +	struct usb_otg      		otg;
You have added *otg* in previous patch and added a tab for *otg* in this 
patch.

> +	bool				id_event;
> +	bool				b_sess_valid_event;
>   };
>
>   static inline struct ci_role_driver *ci_role(struct ci13xxx *ci)
> @@ -314,4 +318,6 @@ int hw_port_test_set(struct ci13xxx *ci, u8 mode);
>
>   u8 hw_port_test_get(struct ci13xxx *ci);
>
> +void ci_handle_vbus_change(struct ci13xxx *ci);
> +
>   #endif	/* __DRIVERS_USB_CHIPIDEA_CI_H */
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index aebf695..f8f8484 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -73,6 +73,7 @@
>   #include "bits.h"
>   #include "host.h"
>   #include "debug.h"
> +#include "otg.h"
>
>   /* Controller register map */
>   static uintptr_t ci_regs_nolpm[] = {
> @@ -199,6 +200,14 @@ static int hw_device_init(struct ci13xxx *ci, void __iomem *base)
>   	if (ci->hw_ep_max > ENDPT_MAX)
>   		return -ENODEV;
>
> +	/* Disable all interrupts bits */
> +	hw_write(ci, OP_USBINTR, 0xffffffff, 0);
> +	ci_disable_otg_interrupt(ci, OTGSC_INT_EN_BITS);
> +
> +	/* Clear all interrupts status bits*/
> +	hw_write(ci, OP_USBSTS, 0xffffffff, 0xffffffff);
> +	ci_clear_otg_interrupt(ci, OTGSC_INT_STATUS_BITS);
> +
>   	dev_dbg(ci->dev, "ChipIdea HDRC found, lpm: %d; cap: %p op: %p\n",
>   		ci->hw_bank.lpm, ci->hw_bank.cap, ci->hw_bank.op);
>
> @@ -265,24 +274,124 @@ static enum ci_role ci_otg_role(struct ci13xxx *ci)
>   }
>
>   /**
> - * ci_role_work - perform role changing based on ID pin
> - * @work: work struct
> + * hw_wait_reg: wait the register value
> + *
> + * Sometimes, it needs to wait register value before going on.
> + * Eg, when switch to device mode, the vbus value should be lower
> + * than OTGSC_BSV before connects to host.
> + *
> + * @ci: the controller
> + * @reg: register index
> + * @mask: mast bit
> + * @value: the bit value to wait
> + * @timeout: timeout to indicate an error
> + *
> + * This function returns an error code if timeout
>    */
> -static void ci_role_work(struct work_struct *work)
> +static int hw_wait_reg(struct ci13xxx *ci, enum ci13xxx_regs reg, u32 mask,
> +				u32 value, unsigned long timeout)
> +{
> +	unsigned long elapse = jiffies + timeout;
> +
> +	while (hw_read(ci, reg, mask) != value) {
> +		if (time_after(jiffies, elapse)) {
> +			dev_err(ci->dev, "timeout waiting for %08x in %d\n",
> +					mask, reg);
> +			return -ETIMEDOUT;
> +		}
> +		msleep(20);
> +	}
> +
> +	return 0;
> +}
> +
> +#define CI_VBUS_STABLE_TIMEOUT 500

Just curious.. how was this timeout value obtained?

Thanks
Kishon

^ permalink raw reply

* [PATCH] ARM: imx: fix imx31-dt.c time-related warning
From: Shawn Guo @ 2013-01-30  6:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1359518177-21245-1-git-send-email-swarren@wwwdotorg.org>

On Tue, Jan 29, 2013 at 08:56:17PM -0700, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
> 
> Commit 6bb27d7 "ARM: delete struct sys_timer" caused the following:
> 
> arch/arm/mach-imx/imx31-dt.c:56:2: warning: initialization from incompatible pointer type [enabled by default]
> arch/arm/mach-imx/imx31-dt.c:56:2: warning: (near initialization for ?__mach_desc_IMX31_DT.init_time?) [enabled by default]
> 
> This is because mx31_clocks_init_dt() returns int, whereas the .init_time
> field prototype expects a function returning void. Implement a wrapper so
> that the prototypes match.
> 
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

Acked-by: Shawn Guo <shawn.guo@linaro.org>

> ---
> This patch is based on arm-soc's timer/cleanup branch, which contains
> the commit mentioned above.

I suppose that it should just be applied by arm-soc folks on that
branch, right?

Shawn

^ permalink raw reply

* [RFC PATCH v2 0/2] ARM: update cpuinfo to print SoC model name
From: Santosh Shilimkar @ 2013-01-30  6:00 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1359506337-21619-1-git-send-email-ruslan.bilovol@ti.com>

On Wednesday 30 January 2013 06:08 AM, Ruslan Bilovol wrote:
> The following patches update cpuinfo to print SoC
> model name for ARM.
> The first patch exactly makes needed changes for ARM
> architecture and adds a common approach to show SoC name.
> Second patch uses this approach for OMAP4 SoCs (as live
> example).
>
> Looks like there were few attempts to do similar
> changes to cpuinfo without any luck (had stuck
> on review) so this functionality is still not
> in the kernel yet.
> In this patch series the update to cpuinfo is very
> short (10 lines) and easy.
>
> Comments are welcome as usual
>
As most of the people already commented, your purpose
behind the series isn't clear so please give examples
where and why you need  device type information from
user-space.

Regards,
Santosh

^ permalink raw reply

* [PATCH] ARM: OMAP2+: Fix selection of clockevent timer when using device-tree
From: Santosh Shilimkar @ 2013-01-30  5:54 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1359490991-17688-1-git-send-email-jon-hunter@ti.com>

On Wednesday 30 January 2013 01:53 AM, Jon Hunter wrote:
> Commit 9725f44 (ARM: OMAP: Add DT support for timer driver) added
> device-tree support for selecting a clockevent timer by property.
> However, the code is currently ignoring the property passed and
> selecting the first available timer found. Hence, for the OMAP3 beagle
> board timer-12 is not being selected as expected. Fix this problem
> by ensuring the timer property is passed to omap_get_timer_dt().
>
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

^ permalink raw reply

* [RFC PATCH 1/2] ARM: kernel: update cpuinfo to print CPU model name
From: Santosh Shilimkar @ 2013-01-30  5:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAB=otbR+MA3NUhxqRdo=w81gz9sTLAsLV5ELcpp77UxizMiaKw@mail.gmail.com>

On Wednesday 30 January 2013 04:42 AM, Ruslan Bilovol wrote:
> Hi,
>
> On Tue, Jan 29, 2013 at 6:08 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Tue, Jan 29, 2013 at 05:54:24PM +0200, Ruslan Bilovol wrote:
>>> CPU implementer : 0x41
>>> CPU name        : OMAP4470 ES1.0 HS
>>
>> Sigh.  No.  Look at what you're doing - look carefully at the above.
>>
>> "CPU implementer" - 0x41.  That's A.  For ARM Ltd.  ARM Ltd implemented
>> this CPU.  Did ARM Ltd really implement OMAP4470 ?  I think TI would be
>> very upset if that were to be the case.
>
> Yes, it would be very surprisingly :)
>
>>
>> So no, OMAP4470 is _NOT_ a CPU.  It is a SoC.  The CPU inside the SoC is
>> a collection of ARM Ltd Cortex A9 _CPUs_.
>>
>> See?  Please, learn what a CPU is as opposed to a SoC.
>
> Completely agree with you. I will fix this
>
Thank god you agreed to drop your current approach. Please elaborate
what you are going to fix and also state what user-space features
changes from OMAP4460 to OMAP4470.

Regards,
Santosh

^ permalink raw reply

* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: kishon @ 2013-01-30  5:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130129203050.GT1906@pengutronix.de>

On Wednesday 30 January 2013 02:00 AM, Sascha Hauer wrote:
> On Tue, Jan 29, 2013 at 07:14:51PM +0530, kishon wrote:
>> Hi,
>>
>> On Tuesday 29 January 2013 04:52 PM, Sascha Hauer wrote:
>>> From: Michael Grzeschik <m.grzeschik@pengutronix.de>
>>>
>>> This adds two little devicetree helper functions for determining the
>>> dr_mode (host, peripheral, otg) and phy_type (utmi, ulpi,...) from
>>> the devicetree.
>>>
>>> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
>>> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
>>> ---
>>>
>>> The properties and their values have been taken from the fsl-mph-dr driver.
>>> This binding is also documented (though currently not used) for the tegra
>>> ehci driver (Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt).
>>> This is a first attempt to parse these bindings at a common place so that
>>> others can make use of it.
>>>
>>> Basically I want to know whether this binding is recommended for new drivers
>>> since normally the devicetree uses '-' instead of '_', and maybe there are
>>> other problems with it.
>>>
>>> I need this binding for the chipidea driver. I suspect that the fsl-mph-dr
>>> driver also really handles a chipidea core.
>>>
>>> Should we agree on this I would convert the fsl-mph-dr driver to use these
>>> helpers.
>>>
>>> Sascha
>>>
>>>   drivers/usb/core/Makefile |    1 +
>>>   drivers/usb/core/of.c     |   76 +++++++++++++++++++++++++++++++++++++++++++++
>>
>> This file should ideally go into drivers/usb/phy/.
>
> I originally wanted to do that, but the host/peripheral/otg property is
> not phy specific. DO you still want to move it there?

I think then you can just move of_usb_get_phy_mode() to phy/of.c.
Then we can also move some functions defined in otg.c (specific to PHY 
and dt) to phy/of.c.

Thanks
Kishon

^ permalink raw reply

* [RFC 3/3] arm: mach-mxs: make enabling enet_out a legacy function
From: Shawn Guo @ 2013-01-30  5:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1359470773-14290-4-git-send-email-w.sang@pengutronix.de>

On Tue, Jan 29, 2013 at 03:46:13PM +0100, Wolfram Sang wrote:
> @@ -351,7 +359,7 @@ static void __init tx28_post_init(void)
>  	struct pinctrl *pctl;
>  	int ret;
>  
> -	enable_clk_enet_out();
> +	legacy_enable_clk_enet_out();

I think TX28 is the only case that really needs to turn on enet_out
clock at platform level, since it has some dirty work about PHY to do
here.  With with fec driver handling the clock, enable_clk_enet_out()
can just be removed for other boards.

Shawn

>  
>  	np = of_find_compatible_node(NULL, NULL, "fsl,imx28-fec");
>  	pdev = of_find_device_by_node(np);

^ permalink raw reply

* [RFC PATCH v2 1/2] ARM: kernel: update cpuinfo to print SoC model name
From: Nishanth Menon @ 2013-01-30  5:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1359506337-21619-2-git-send-email-ruslan.bilovol@ti.com>

On Tue, Jan 29, 2013 at 6:38 PM, Ruslan Bilovol <ruslan.bilovol@ti.com> wrote:
>
> SoC name        : OMAP4470 ES1.0 HS
I am sorry, but I have to NAK for specifically reasons explained in
http://marc.info/?l=linux-omap&m=135950276616961&w=2

I just dont think SoC information belongs in /proc/cpuinfo. nor is SoC
name "OMAP4470 ES1.0 HS" -> it is just OMAP4470.

Regards,
Nishanth Menon

^ permalink raw reply

* [RFC 1/3] net: freescale: fec: add support for optional enet_out clk
From: Shawn Guo @ 2013-01-30  5:25 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1359470773-14290-2-git-send-email-w.sang@pengutronix.de>

Thanks for working on this, Wolfram.

On Tue, Jan 29, 2013 at 03:46:11PM +0100, Wolfram Sang wrote:
> Some MX28 boards need the internal enet_out clock to be enabled. So, do
> this in the driver iff the clock was referenced via devicetree.
> 
> Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>

Acked-by: Shawn Guo <shawn.guo@linaro.org>

> ---
> 
> davidm: Please don't apply before Shawn as the mxs-maintainer has given his ack
> on the general procedure. Or maybe he can merge it via his tree?
> 
I prefer to have the patch go via net tree for 3.9, and then we clean
up mxs platform code from 3.9-rc1.

Shawn

^ permalink raw reply

* [PATCH v2 3/5] ARM: make the platforms not to select the l2x0 erratas
From: Srinidhi Kasagar @ 2013-01-30  5:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5107DD5C.9020203@gmail.com>

On Tue, Jan 29, 2013 at 15:31:56 +0100, Rob Herring wrote:
> On 01/29/2013 04:15 AM, srinidhi kasagar wrote:
> > Make the platforms not to choose the Errata's explicitly
> 
> Why?

Because I have two platforms where one suffers from a Errata whereas other
do not, but shares the same defconfig. Basically, I wanted to avoid 
choosing these Errata's during build time and tried to make the decisions
at run time rather...but, that looks like it's not going in the right 
direction..let me rework on the series.

Thanks,srinidhi
> 
> > 
> > Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
> > ---
> >  arch/arm/mach-imx/Kconfig      |    3 ---
> >  arch/arm/mach-omap2/Kconfig    |    2 --
> >  arch/arm/mach-tegra/Kconfig    |    3 ---
> >  arch/arm/mach-ux500/Kconfig    |    1 -
> >  arch/arm/mach-vexpress/Kconfig |    1 -
> >  5 files changed, 0 insertions(+), 10 deletions(-)
> > 
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index 3e628fd..8ed6672 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -855,9 +855,6 @@ config SOC_IMX6Q
> >  	select MFD_SYSCON
> >  	select PINCTRL
> >  	select PINCTRL_IMX6Q
> > -	select PL310_ERRATA_588369 if CACHE_PL310
> > -	select PL310_ERRATA_727915 if CACHE_PL310
> > -	select PL310_ERRATA_769419 if CACHE_PL310
> >  	select PM_OPP if PM
> >  
> >  	help
> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> > index 41b581f..7612c07 100644
> > --- a/arch/arm/mach-omap2/Kconfig
> > +++ b/arch/arm/mach-omap2/Kconfig
> > @@ -67,8 +67,6 @@ config ARCH_OMAP4
> >  	select HAVE_SMP
> >  	select LOCAL_TIMERS if SMP
> >  	select OMAP_INTERCONNECT
> > -	select PL310_ERRATA_588369
> > -	select PL310_ERRATA_727915
> >  	select PM_OPP if PM
> >  	select PM_RUNTIME if CPU_IDLE
> >  	select USB_ARCH_HAS_EHCI if USB_SUPPORT
> > diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
> > index b442f15..f6214f5 100644
> > --- a/arch/arm/mach-tegra/Kconfig
> > +++ b/arch/arm/mach-tegra/Kconfig
> > @@ -15,8 +15,6 @@ config ARCH_TEGRA_2x_SOC
> >  	select CPU_V7
> >  	select PINCTRL
> >  	select PINCTRL_TEGRA20
> > -	select PL310_ERRATA_727915 if CACHE_L2X0
> > -	select PL310_ERRATA_769419 if CACHE_L2X0
> >  	select USB_ARCH_HAS_EHCI if USB_SUPPORT
> >  	select USB_ULPI if USB
> >  	select USB_ULPI_VIEWPORT if USB_SUPPORT
> > @@ -36,7 +34,6 @@ config ARCH_TEGRA_3x_SOC
> >  	select CPU_V7
> >  	select PINCTRL
> >  	select PINCTRL_TEGRA30
> > -	select PL310_ERRATA_769419 if CACHE_L2X0
> >  	select USB_ARCH_HAS_EHCI if USB_SUPPORT
> >  	select USB_ULPI if USB
> >  	select USB_ULPI_VIEWPORT if USB_SUPPORT
> > diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
> > index 5dea906..db13db5 100644
> > --- a/arch/arm/mach-ux500/Kconfig
> > +++ b/arch/arm/mach-ux500/Kconfig
> > @@ -11,7 +11,6 @@ config UX500_SOC_COMMON
> >  	select COMMON_CLK
> >  	select PINCTRL
> >  	select PINCTRL_NOMADIK
> > -	select PL310_ERRATA_753970 if CACHE_PL310
> >  
> >  config UX500_SOC_DB8500
> >  	bool
> > diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> > index 52d315b..c658c40 100644
> > --- a/arch/arm/mach-vexpress/Kconfig
> > +++ b/arch/arm/mach-vexpress/Kconfig
> > @@ -42,7 +42,6 @@ config ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA
> >  	bool "Enable A5 and A9 only errata work-arounds"
> >  	default y
> >  	select ARM_ERRATA_720789
> > -	select PL310_ERRATA_753970 if CACHE_PL310
> >  	help
> >  	  Provides common dependencies for Versatile Express platforms
> >  	  based on Cortex-A5 and Cortex-A9 processors. In order to
> > 
> 

^ permalink raw reply

* [PATCH v1 1/5] ARM: cache-l2x0: add 'smc' identifier
From: Srinidhi Kasagar @ 2013-01-30  5:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130129122255.GI2637@n2100.arm.linux.org.uk>

On Tue, Jan 29, 2013 at 13:22:56 +0100, Russell King - ARM Linux wrote:
> On Tue, Jan 29, 2013 at 05:19:27PM +0530, Srinidhi Kasagar wrote:
> > On Tue, Jan 29, 2013 at 12:33:25 +0100, Russell King - ARM Linux wrote:
> > > On Tue, Jan 29, 2013 at 03:43:31PM +0530, srinidhi kasagar wrote:
> > > > Add 'smc' (Secure Monitor Call) identifier to differentiates
> > > > the platforms which implements this.
> > > 
> > > This patch makes no sense.
> > > 
> > > So, if setting 'smc' in the DT description is supposed to mean that
> > > the platform has a secure monitor then...
> > > 
> > > > +	is_smc = of_property_read_bool(np, "smc");
> > > > +
> > > > +	if (is_smc) {
> > > > +		/* set the debug interface */
> > > > +		outer_cache.set_debug = pl310_set_debug;
> > > > +	}
> > > 
> > > Now, let's look at what pl310_set_debug() does:
> > > 
> > > static void pl310_set_debug(unsigned long val)
> > > {
> > >         writel_relaxed(val, l2x0_base + L2X0_DEBUG_CTRL);
> > 
> > You can do this operation (write to DEBUG_CTRL) only if SMC is implemented.
> 
> Err... no.  You can do it if you're running in secure mode without a
> secure monitor, because the security stuff doesn't get in the way.

Yes, you are right as always. I was totally wrong, I overlooked the code.
I will drop this patch, it does not make sense.

> 
> What other platforms do is up to them, and up to *how* the secure monitor
> is implemented, not *if*.
> 
> > > }
> > > 
> > > Can you explain where the secure monitor call is there please, because
> > > I can't see one.  In fact, this is the function used when there _isn't_
> > > a secure monitor.  So this patch just seems totally wrong to me.
> 
> So this is going to be difficult because you only ever answer half an
> email?  So, I repeat the question above.
Yes, there is no secure monitor call. I mixed up two things and end up in a mess.

Thanks,srinidhi

^ permalink raw reply

* [PATCH] ARM:mach-msm: seting tail NUL after strncpy
From: Chen Gang @ 2013-01-30  5:01 UTC (permalink / raw)
  To: linux-arm-kernel


  temp need NUL terminated, or next ptr may cause issue.

Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/arm/mach-msm/clock-debug.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mach-msm/clock-debug.c
b/arch/arm/mach-msm/clock-debug.c
index 4886404..bdca900 100644
--- a/arch/arm/mach-msm/clock-debug.c
+++ b/arch/arm/mach-msm/clock-debug.c
@@ -105,6 +105,8 @@ int __init clock_debug_add(struct clk *clock)
 		return -ENOMEM;

 	strncpy(temp, clock->dbg_name, ARRAY_SIZE(temp)-1);
+	temp[ARRAY_SIZE(temp)-1] = '\0';
+
 	for (ptr = temp; *ptr; ptr++)
 		*ptr = tolower(*ptr);

-- 
1.7.10.4

^ permalink raw reply related

* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Jason Gunthorpe @ 2013-01-30  4:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201301291645.08040.arnd@arndb.de>

On Tue, Jan 29, 2013 at 04:45:07PM +0000, Arnd Bergmann wrote:
> On Tuesday 29 January 2013, Thomas Petazzoni wrote:
> > And the Linux PCI resource allocation code complies with this, so that
> > if I have two PCI-to-PCI bridges (each having downstream a device with
> > an I/O BAR), then the first PCI-to-PCI bridge gets its I/O base address
> > register set to ADDR + 0x0, and the second bridge gets its I/O base
> > address set to ADDR + 0x1000. And this doesn't play well with the
> > requirements of Marvell address decoding windows for PCIe I/O regions,
> > which must be 64 KB aligned.
> 
> But we normally only assign a 64 KB I/O window to each PCI host bridge.
> Requiring PCI bridges to be space 64 KB apart would mean that we cannot
> actually support bridges at all.

The PCI resource code uses full 32 bit integers when it handles IO
addresses, so this actually does sort of work out.

However, Thomas how did you recover the high bits of the
IO window address from the bridge configuration? Are you reading the
struct resource directly? That probably causes problems with
hotplug/etc...

If you look back in your old emails I outlined a solution to this
using the MMU.

Jason

^ permalink raw reply

* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Jason Gunthorpe @ 2013-01-30  4:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130129225932.01efb45b@skate>

On Tue, Jan 29, 2013 at 10:59:32PM +0100, Thomas Petazzoni wrote:
> Arnd,
> 
> On Tue, 29 Jan 2013 21:33:08 +0100, Thomas Petazzoni wrote:
> 
> > Basically, I have currently two suggestions:
> > 
> >  * From Jason Gunthorpe, to not use any host bridge, and instead use
> >    only PCI-to-PCI bridges, one per PCIe interface.
> > 
> >  * From you, to not use any PCI-to-PCI bridge, and use only host
> >    bridges, one per PCIe interface.

Arnd is suggesting to use multiple *linux* host bridges (ie host
drivers), there is never any need for a 'host bridge config space' as
in patch #7, in either case.

> However, one of the reason to use a PCI-to-PCI bridge was to ensure
> that the PCIe devices were all listed in slot 0. According to the
> Marvell engineers who work on the PCIe stuff, some new PCIe devices
> have this requirement. I don't have a lot of details about this, but I
> was told that most of the new Intel NICs require this, for example the
> Intel X520 fiber NIC. Maybe PCIe experts (Jason?) could provide more
> details about this, and confirm/infirm this statement.

I'm not sure what this is referring to.. I don't recall any specific
requirements in PCI-E for the device number, I think the spec requires
it to be learned based on the config TLPs received.

There might be a device number sensitivity in INTx translation, but
that is defined by the spec.

That said, if your root complex is PCI-E compliant then all downstream
end ports attached to a root port should have a device number of 0.

> The usage of PCI-to-PCI bridge allows to have each PCIe device on its
> own bus, at slot 0, which also solves this problem.

Hrm....

Looking at the docs, you will also need to change the internal device
number (probably reg 41a04 again) to something other than 0, otherwise
the Marvell itself will claim device number 0 and the downstream end
port will be device number 1. You should see this happen today??

You should set the Marvell internal device number to something like
all ones and then deny any Linux config register access to the all
ones device number on the subordinate bus to hide the Marvell end port
config space registers from Linux.

As for as this process goes, it doesn't matter which approach you
take. If you use multiple PCI domains then you'd still be able to
arrange things via the above so that the downstream device could
always claim device number 0.

Jason

^ permalink raw reply

* [PATCH RESEND v2] ARM: EXYNOS: dts: Set up power domain for MFC and G-scaler
From: Prasanna Kumar @ 2013-01-30  4:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <06e301cdfe51$f11b59c0$d3520d40$@samsung.com>

This patch adds device tree nodes for MFC and G-scaler power
domains of exynos5250.It binds these power-domain nodes to repsective
device tree nodes

It also adds support to enable PM generic domains for exynos5250.

Signed-off-by: Prasanna Kumar <prasanna.ps@samsung.com>
---
 arch/arm/boot/dts/exynos5250.dtsi |   16 ++++++++++++++++
 arch/arm/mach-exynos/Kconfig      |    1 +
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
index 30485de..e282fde 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -46,6 +46,16 @@
 		i2c8 = &i2c_8;
 	};
 
+	pd_gsc: gsc-power-domain at 0x10044000 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x10044000 0x20>;
+	};
+
+	pd_mfc: mfc-power-domain at 0x10044040 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x10044040 0x20>;
+	};
+
 	gic:interrupt-controller at 10481000 {
 		compatible = "arm,cortex-a9-gic";
 		#interrupt-cells = <3>;
@@ -85,6 +95,7 @@
 		compatible = "samsung,mfc-v6";
 		reg = <0x11000000 0x10000>;
 		interrupts = <0 96 0>;
+		samsung,power-domain = <&pd_mfc>;
 	};
 
 	rtc {
@@ -554,28 +565,33 @@
 		};
 	};
 
+
 	gsc_0:  gsc at 0x13e00000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e00000 0x1000>;
 		interrupts = <0 85 0>;
+		samsung,power-domain = <&pd_gsc>;
 	};
 
 	gsc_1:  gsc at 0x13e10000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e10000 0x1000>;
 		interrupts = <0 86 0>;
+		samsung,power-domain = <&pd_gsc>;
 	};
 
 	gsc_2:  gsc at 0x13e20000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e20000 0x1000>;
 		interrupts = <0 87 0>;
+		samsung,power-domain = <&pd_gsc>;
 	};
 
 	gsc_3:  gsc at 0x13e30000 {
 		compatible = "samsung,exynos5-gsc";
 		reg = <0x13e30000 0x1000>;
 		interrupts = <0 88 0>;
+		samsung,power-domain = <&pd_gsc>;
 	};
 
 	hdmi {
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index e103c29..96f4a9f 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -61,6 +61,7 @@ config SOC_EXYNOS5250
 	bool "SAMSUNG EXYNOS5250"
 	default y
 	depends on ARCH_EXYNOS5
+	select PM_GENERIC_DOMAINS if PM
 	select S5P_PM if PM
 	select S5P_SLEEP if PM
 	select S5P_DEV_MFC
-- 
1.7.5.4

^ permalink raw reply related

* [PATCH 3/5] serial: pl011: use generic DMA slave configuration if possible
From: Greg Kroah-Hartman @ 2013-01-30  4:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1359410300-26113-4-git-send-email-arnd@arndb.de>

On Mon, Jan 28, 2013 at 09:58:18PM +0000, Arnd Bergmann wrote:
> With the new OF DMA binding, it is possible to completely avoid the
> need for platform_data for configuring a DMA channel. In cases where the
> platform has already been converted, calling dma_request_slave_channel
> should get all the necessary information from the device tree.
> 
> This also adds a binding document specific to the pl011 controller,
> and extends the generic primecell binding to mention "dmas" and other
> common properties.
> 
> Like the patch that converts the dw_dma controller, this is completely
> untested and is looking for someone to try it out.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Jiri Slaby <jslaby@suse.cz>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: spi-devel-general at lists.sourceforge.net
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Cc: Vinod Koul <vinod.koul@linux.intel.com>
> Cc: devicetree-discuss at lists.ozlabs.org
> Cc: linux-arm-kernel at lists.infradead.org

Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

^ permalink raw reply

* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: 이경식 @ 2013-01-30  4:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20130129225508.GC30535@twin.jikos.cz>

> > It seems that it?s worth trying LZ4 compressed kernel image or ramdisk
> > for making the kernel boot more faster.
> 
> There's another potential user of lz4: btrfs. I've submitted a feature
> preview integrating lz4 compression
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/15744
> and we have tried to integrate the HC mode as well
> http://thread.gmane.org/gmane.comp.file-systems.btrfs/18165
> .
> So far it's on a slow track, conceptually it works, but I the code needs
> some work so it could live under lib/* (we've used the svn sources with
> minor changes, no kernel coding style). It would be easier for me to
> enhance the existing lib/lz4/* codebase.
> 
I don't know much about btrfs. But I guess the lz4 related APIs should
be migrated and integrated under lib/lz4/* like the way lzo implemented.

> Also zram could consider lz4, I'm not sure if there are other potential
> users.
> 
> 
> david

Thanks,
Kyungsik

^ permalink raw reply

* [PATCH v2 1/2] ARM: kirkwood: Ensure that kirkwood_ge0[01]_init() finds its clock
From: Jason Cooper @ 2013-01-30  4:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <51086E86.8040705@gmail.com>

On Wed, Jan 30, 2013 at 01:51:18AM +0100, Sebastian Hesselbarth wrote:
> On 01/30/2013 01:03 AM, Simon Baatz wrote:
> >On Tue, Jan 29, 2013 at 09:08:46PM +0100, Sebastian Hesselbarth wrote:
> >>Well, if there is no device/driver using runit it should be safe to disable
> >>it. If there is a driver using it, we need a clocks property for it. And
> >>as you already stated, serial is using it. And you want serial in every
> >>minimal kernel, don't you?
> >
> > From f479db4:
> >
> >  Marvell engineers tell us:
> >
> >  It seems that many units use the RUNIT clock.
> >  SPI, UART, NAND, TWSI, ...
> >  So it's not possible to clock gate it.
> >
> >  Currently the SPI, NAND and TWSI driver will clk_prepaure_enable()
> >  this clk, but since we have no idea what ... is, and turning this clk
> >  off results in a hard lock, unconditionally enable runit.
> >
> >
> >Thus, if we know better than that, that's fine, but please don't tell
> >me that this is "blindly" enabling clocks.

'blindly' is the correct term.  I'm sorry, I'm not trying to be
difficult, but I don't like applying a 'fix' because a 'Marvell
engineer' was too f'ing lazy to figure out wtf was going on with the
runit clock.

So what happens if runit is gated?  Here's what I did to find out:

######
$ git checkout -b runit v3.8-rc5
$ make kirkwood_defconfig
$ ./scripts/config -e COMMON_CLK_DEBUG -e NETCONSOLE \
	-d SERIAL_OF_PLATFORM -d ORION_WATCHDOG \
	-d SPI_ORION -d MTD_NAND_ORION -d I2C_MV64XXX

$ make uImage dtbs

# edit kernel cmdline in u-boot:

Marvell>> setenv bootargs 'console=null rootwait root=/dev/sda2 netconsole=@192.168.1.253/eth0, at 192.168.1.196/ff:ff:ff:ff:ff:ff'
Marvell>> boot

$ socat udp-recv:6666 -
<small pause here>
EXT3-fs (sda2): warning: maximal mount count reached, running e2fsck is recommended
EXT3-fs (sda2): using internal journal
<smaller pause here>>
Unable to handle kernel NULL pointer dereference at virtual address 00000000
#######

It boots all the way up to mounting the USB attached uSD card rootfs.

A few notes about this test setup:
 - the rootfs still has a getty on ttyS0 (could be causing above NULL?)
 - I haven't setup networking on it yet (I was just debugging
   mv643xx_eth gated clock issue).

All this tells me the kernel *does* boot with runit gated since all
drivers that would grab it are disabled.  Tomorrow I'll setup dhcp and
sshd and try to mount debugfs to see if runit is indeed disabled.
Unless someone gets to it before me ;-)

I'll get to the below tomorrow.

thx,

Jason.

> Hmm, should have seen that comment ealier. Based on your/Andrew's statement
> above using CLK_IGNORE_UNUSED on runit maybe is the best.
> 
> So I guess we take patch 2/2 and extend DT clock gating for .flags later?
> 
> >So, we have a statement from Marvell not to gate it, we know that it
> >is needed for "...", can we please not gate it?
> 
> Ack.


> 
> >>>>>3.8-rc5 + runit + Sebastians get smi clock patch (modified to use
> >>>>>legacy clock names):
> >>>>>
> >>>>>DT: Boots, but no MAC
> >>>>>non-DT: Boots ok
> >>>
> >>>This is the behavior originally found by Andrew. The clock patch
> >>>eliminates the lockup, but the hardware forgets its MAC address.
> 
> For the smi clock issue: DT is fixed by the smi clock patch, right?
> non-DT should be fixed in kirkwood_clk_init() with an orion_clkdev_add()
> alias for MV643XX_ETH_SHARED_NAME ".0" and ".1" respectively.
> 
> For the MAC address issue: non-DT doesn't need to be fixed, right?
> DT clock gates should be fixed in kirkwood_legacy_clk_init which will
> also save the clk_get_sys() call. We can easily remove it when mv643xx_eth
> catches the MAC address from either local-mac-address or ATAG.
> 
> >Fine with all of that. But: I am talking about 3.8 all the time. We
> >have three options for issues 2 and 3 from my point of view:
> >
> >1. We do proper fixes in 3.8 for issues 2 and 3.
> >
> >2. We fix this regression by not gating the clock in both the DT and
> >the non-DT case, preferably by using the correct clocks in
> >kirkwood_ge0[01]_init().  Additionally, Jason promises that all gets
> >well with the DT aware driver in 3.9.  ;-)
> >
> >3. Do nothing. Simply accept that we broke modular Ethernet for DT
> >because some code relies on two pointers being set.  When we
> >introduced a new code path for DT, we forgot about these pointers.
> >Bad luck, the solution was not nice anyway and we will do proper
> >fixes in 3.9.
> >
> >As should be clear by now, I think we should go for option 2.
> 
> Agreed, do you think all issues you are suffering will be solved with:
> 
> - [PATCH v2 2/2] clk: mvebu: Do not gate runit clock on Kirkwood
>   (no lockup for minimal kernel configs)

fix for v3.8-rc

> - [PATCH] NET: mv643xx: get smi clock from device tree
>   (no lockup for modular DT ethernet)
> 
> - Some patch that adds MV643XX_ETH_SHARED_NAME ".0" and ".1" clk aliases
>   (no lockup for modular non-DT ethernet)
> 
> - Some patch that adds clk_prepare_enable to ge0/ge1 clocks to
>   kirkwood_legacy_clk_init()
>   (retain MAC address for modular DT ethernet)
> 
> I'll prepare the latter patches and post them.
> 
> Sebastian

^ permalink raw reply

* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Jason Gunthorpe @ 2013-01-30  4:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAErSpo41TbWTZ_6m0_uv-EaKnnqMR9jpqsarOJLGYZ31mrdkiw@mail.gmail.com>

On Tue, Jan 29, 2013 at 03:27:43PM -0700, Bjorn Helgaas wrote:

> I'm not sure the existing emulation in these patches is sufficient.
> For example, pci_sw_pci_bridge_write() updates bridge->membase when we
> write to the window register, but I don't see anything that updates
> the actual hardware decoder.  That might be done in
> mvebu_pcie_window_config_port() via armada_370_xp_alloc_pcie_window(),
> but that looks like it's only done once.  If the PCI core updates a
> root port window later, I don't see where the hardware decoder will be
> updated.
> 
> Maybe you're counting on the window assignments to be static?  The PCI
> core doesn't guarantee anything like that, though in the absence of
> hotplug I don't know any reason why it would change things.
 
Agree..

Thomas, I think you need to directly update the Marvell hardware
registers when config writes are made to the SW bridge. If this means
it is too hard/complex to keep the code general then I'd say make it
part of the Marvell host driver.

> I also forgot about the bus number munging in mvebu_pcie_rd_conf().
> The PCI core can update the bridge secondary/subordinate registers.
> It looks like you don't support writing to them, and the read path
> (pci_sw_pci_bridge_read()) looks like it doesn't do any translation
> between the hardware and Linux bus numbers.  I don't understand the
> system well enough to know if this is an issue.

I was chatting with Thomas on this subject, it looks like there is a
HW register that needs to be set to the subordinate bus number of the
bridge, that will solve this weirdness.

Jason

^ permalink raw reply

* [PATCH] ARM: shmobile: armadillo800eva: set clock rates before timer init
From: Simon Horman @ 2013-01-30  4:23 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1358485325-19673-1-git-send-email-hdk@igel.co.jp>

On Fri, Jan 18, 2013 at 02:02:05PM +0900, Hideki EIRAKU wrote:
> Previously clock rates were set after initialization of timer.
> Therefore the timer used the default extal1 clock rate (25MHz)
> instead of the correct rate for this board (24MHz).
> 
> Signed-off-by: Hideki EIRAKU <hdk@igel.co.jp>

Thanks, I have applied this to the boards2 branch
and will merge it into the next branch.

^ permalink raw reply

* [PATCH 1/2] ARM: shmobile: sh73a0: Add CPU sleep suspend
From: Simon Horman @ 2013-01-30  4:22 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CABYn4swp_DGZTSWm+Otc_xwx4pDS7quUop5RNMH+32mjuGZj5g@mail.gmail.com>

On Sat, Jan 12, 2013 at 04:43:29PM +0100, Bastian Hecht wrote:
> Hi Guennadi, hi Simon,
> 
> yes somehow a chunk is missing from my original patch in the patch of
> the next branch that got merged from soc2. I've prepared a revert of
> the bad patch and a corrected version, but now I'm unsure if that
> helps at all. Finally you don't want to get that fixups pulled into
> the mainline.
> 
> It seems to me to be a real mess to correct some patch somewhere in
> the middle of merged patch stacks. If I can help Simon, please let me
> know.

Could you see if the following is correct?
If not could you please prepare whichever of the following makes sense.

* An incremental patch to add the missing hunk

* A revert patch and a new patch

* A revert patch

http://git.kernel.org/?p=linux/kernel/git/horms/renesas.git;a=commitdiff;h=13baf88bd69ed3cf7e2374eec4a7128f62ae9c1f


>From 13baf88bd69ed3cf7e2374eec4a7128f62ae9c1f Mon Sep 17 00:00:00 2001
From: Bastian Hecht <hechtb@gmail.com>
Date: Wed, 5 Dec 2012 12:13:06 +0000
Subject: [PATCH] ARM: shmobile: sh73a0: Add CPU sleep suspend

Add the lighest possible sleep mode on Cortex-A9 cores: CPU sleep. It is
entered by a simple dsb and wfi instruction via cpu_do_idle(). As just
clocks are stopped there is no need to save or restore any state of the
system.

Signed-off-by: Bastian Hecht <hechtb+renesas@gmail.com>
Acked-by: Magnus Damm <damm@opensource.se>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm/mach-shmobile/Makefile              |    1 +
 arch/arm/mach-shmobile/board-kzm9g.c         |    2 ++
 arch/arm/mach-shmobile/include/mach/common.h |    1 +
 arch/arm/mach-shmobile/pm-sh73a0.c           |   32 ++++++++++++++++++++++++++
 4 files changed, 36 insertions(+)
 create mode 100644 arch/arm/mach-shmobile/pm-sh73a0.c

diff --git a/arch/arm/mach-shmobile/Makefile b/arch/arm/mach-shmobile/Makefile
index 0b71479..f6aba6d 100644
--- a/arch/arm/mach-shmobile/Makefile
+++ b/arch/arm/mach-shmobile/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_ARCH_SHMOBILE)	+= pm-rmobile.o
 obj-$(CONFIG_ARCH_SH7372)	+= pm-sh7372.o sleep-sh7372.o
 obj-$(CONFIG_ARCH_R8A7740)	+= pm-r8a7740.o
 obj-$(CONFIG_ARCH_R8A7779)	+= pm-r8a7779.o
+obj-$(CONFIG_ARCH_SH73A0)	+= pm-sh73a0.o
 
 # Board objects
 obj-$(CONFIG_MACH_AP4EVB)	+= board-ap4evb.o
diff --git a/arch/arm/mach-shmobile/board-kzm9g.c b/arch/arm/mach-shmobile/board-kzm9g.c
index ac94285..363c6ed 100644
--- a/arch/arm/mach-shmobile/board-kzm9g.c
+++ b/arch/arm/mach-shmobile/board-kzm9g.c
@@ -772,6 +772,8 @@ static void __init kzm_init(void)
 
 	sh73a0_add_standard_devices();
 	platform_add_devices(kzm_devices, ARRAY_SIZE(kzm_devices));
+
+	sh73a0_pm_init();
 }
 
 static void kzm9g_restart(char mode, const char *cmd)
diff --git a/arch/arm/mach-shmobile/include/mach/common.h b/arch/arm/mach-shmobile/include/mach/common.h
index 2d1686b..f221c11 100644
--- a/arch/arm/mach-shmobile/include/mach/common.h
+++ b/arch/arm/mach-shmobile/include/mach/common.h
@@ -40,6 +40,7 @@ extern void sh73a0_add_early_devices(void);
 extern void sh73a0_add_standard_devices(void);
 extern void sh73a0_clock_init(void);
 extern void sh73a0_pinmux_init(void);
+extern void sh73a0_pm_init(void);
 extern struct clk sh73a0_extal1_clk;
 extern struct clk sh73a0_extal2_clk;
 extern struct clk sh73a0_extcki_clk;
diff --git a/arch/arm/mach-shmobile/pm-sh73a0.c b/arch/arm/mach-shmobile/pm-sh73a0.c
new file mode 100644
index 0000000..99086e9
--- /dev/null
+++ b/arch/arm/mach-shmobile/pm-sh73a0.c
@@ -0,0 +1,32 @@
+/*
+ * sh73a0 Power management support
+ *
+ *  Copyright (C) 2012 Bastian Hecht <hechtb+renesas@gmail.com>
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+
+#include <linux/suspend.h>
+#include <mach/common.h>
+
+#ifdef CONFIG_SUSPEND
+static int sh73a0_enter_suspend(suspend_state_t suspend_state)
+{
+	cpu_do_idle();
+	return 0;
+}
+
+static void sh73a0_suspend_init(void)
+{
+	shmobile_suspend_ops.enter = sh73a0_enter_suspend;
+}
+#else
+static void sh73a0_suspend_init(void) {}
+#endif
+
+void __init sh73a0_pm_init(void)
+{
+	sh73a0_suspend_init();
+}
-- 
1.7.10.4

^ permalink raw reply related

* [PATCH v2 05/27] arm: pci: add a align_resource hook
From: Jason Gunthorpe @ 2013-01-30  4:21 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201301292254.01069.arnd@arndb.de>

On Tue, Jan 29, 2013 at 10:54:00PM +0000, Arnd Bergmann wrote:

> I'm actually fine with either of the two suggestions you mentioned above,
> whichever is easier to implement and/or more closely matches what the
> hardware actually implements is better IMHO.
> 
> The part that I did not like about having emulated PCI-to-PCI bridges
> is that it seems to just work around a (percieved or real) limitation
> in the Linux kernel by adding a piece of infrastructure, rather than
> lifting that limitation by making the kernel deal with what the
> hardware provides. That reminded me of the original mach-vt8500

Well.. in this case there is a standard - PCI-E for what HW vendors
are supposed to do. The kernel core code follows it and works with
compliant hardware.

Marvell HW is not compliant.

So..

Should the kernel core PCI code support this particular non-compliance?
Should the driver work around the non-compliance and present a
compliant interface to the kernel and userspace?

My take is the kernel core PCI code is fine, and I hope
this will be an isolated issue with one family of Marvell IP. So
working around the HW problem in the driver seems best.

If we learn of many more instances like this then, yah, update the
core code and rip out this driver work around...

Jason

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox