* [PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Lothar Waßmann @ 2013-01-17 11:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5Chu0bcXPqn+wWHwAqLu+27DvLx1=Bzaffpd-bA2ahaAQ@mail.gmail.com>
Hi,
Fabio Estevam writes:
> On Thu, Jan 17, 2013 at 8:01 AM, Peter Chen <peter.chen@freescale.com> wrote:
>
> > /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
> > - if (!cpu_is_mx51()) {
> > + if (!strcmp(pdev->id_entry->name, "imx-udc-mx27")) {]]
>
> Shouldn't this be:
> if (!strcmp(pdev->id_entry->name, "imx-udc-mx51"))
>
The equivalent of !cpu_is_mx51() would be
strcmp(pdev->id_entry->name, "imx-udc-mx51") (without the '!') meaning
id_entry->name is different from "imx-udc-mx51".
I personally hate the '!strcmp()' notation and prefer 'strcmp() == 0'
though they are technically equivalent. Using '==' makes it much
clearer to the reader what is intended.
!strcmp() lets one assume that it is true when the comparison fails,
though actually the opposite is true.
Lothar Wa?mann
--
___________________________________________________________
Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________
^ permalink raw reply
* [PATCH v2] mtd: vt8500: Add support for Wondermedia Serial Flash Controller
From: Artem Bityutskiy @ 2013-01-17 11:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358272414-6266-1-git-send-email-linux@prisktech.co.nz>
On Wed, 2013-01-16 at 06:53 +1300, Tony Prisk wrote:
> This patch adds support for the Wondermedia serial flash controller
> found on WM8505, WM8650 and WM8850 SoCs.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
> ---
> v2:
> Change Kconfig depends to ARCH_VT8500 as this driver can't be used on other
> platforms.
Sparse still complains:
@@ @@
+drivers/mtd/devices/wmt_sflash.c:442:24: warning: cast removes address space of expression [sparse]
+drivers/mtd/devices/wmt_sflash.c:458:17: warning: incorrect type in argument 1 (different address spaces) [sparse]
+drivers/mtd/devices/wmt_sflash.c:458:17: expected void volatile [noderef] <asn:2>*<noident> [sparse]
+drivers/mtd/devices/wmt_sflash.c:458:17: got unsigned char [usertype] *<noident> [sparse]
+drivers/mtd/devices/wmt_sflash.c:465:25: warning: incorrect type in argument 1 (different address spaces) [sparse]
+drivers/mtd/devices/wmt_sflash.c:465:25: expected void volatile [noderef] <asn:2>*<noident> [sparse]
+drivers/mtd/devices/wmt_sflash.c:465:25: got unsigned char [usertype] *<noident> [sparse]
Also, checkpatch.pl has a valid complaint:
WARNING:CONFIG_DESCRIPTION: please write a paragraph that describes the config symbol fully
#26: FILE: drivers/mtd/devices/Kconfig:131:
+config MTD_WMT_SFLASH
total: 0 errors, 1 warnings, 636 lines checked
...
> +/* WinBond */
> +#define WB_W25X40BV 0x3013 /* 512 KB */
> +#define WB_X16A 0x3015 /* 2 MB */
> +#define WB_X32 0x3016 /* 4 MB */
> +#define WB_X64 0x3017 /* 8 MB */
> +
> +
> +#define SF_ID(mfr, mdl) ((mfr << 16) | mdl)
The flash manufacturer IDs are not specific to this driver, and should
be defined in a common header.
> +
> +#define FLASH_UNKNOWN 0x00ffffff
> +
> +struct wmt_flash_id {
> + u32 id;
> + u32 size; /* Size in KB */
> +};
> +
> +static struct wmt_flash_id flash_ids[] = {
> + { SF_ID(MFR_SPANSION, SPAN_FL016A), 2048 },
> + { SF_ID(MFR_SPANSION, SPAN_FL064A), 8192 },
> + { SF_ID(MFR_EON, EON_25P16), 2048 },
> + { SF_ID(MFR_EON, EON_25P64), 8192 },
> + { SF_ID(MFR_EON, EON_25F40), 512 },
> + { SF_ID(MFR_EON, EON_25F16), 2048 },
> + { SF_ID(MFR_ATMEL, AT_25DF041A), 512 },
> + { SF_ID(MFR_NUMONYX, NX_25P16), 2048 },
> + { SF_ID(MFR_NUMONYX, NX_25P64), 8192 },
> + { SF_ID(MFR_FUDAN, FM_25F04), 512 },
> + { SF_ID(MFR_SST, SST_VF016B), 2048 },
> + { SF_ID(MFR_MXIC, MX_L512), 64 },
> + { SF_ID(MFR_MXIC, MX_L4005A), 512 },
> + { SF_ID(MFR_MXIC, MX_L1605D), 2048 },
> + { SF_ID(MFR_MXIC, MX_L3205D), 4192 },
> + { SF_ID(MFR_MXIC, MX_L6405D), 8192 },
> + { SF_ID(MFR_MXIC, MX_L1635D), 2048 },
> + { SF_ID(MFR_MXIC, MX_L3235D), 4192 },
> + { SF_ID(MFR_MXIC, MX_L12805D), 16384 },
> + { SF_ID(MFR_WINBOND, WB_W25X40BV), 512 },
> + { SF_ID(MFR_WINBOND, WB_X16A), 2048 },
> + { SF_ID(MFR_WINBOND, WB_X32), 4096 },
> + { SF_ID(MFR_WINBOND, WB_X64), 8192 },
> + { 0, 0 },
> +};
Probably this should also be outside of the driver, since it is not
specific to this driver.
> +static u32 sf_get_chip_size(struct device *dev, u32 id)
> +{
> + int i;
> + for (i = 0; flash_ids[i].id != 0; i++)
> + if (flash_ids[i].id == id)
> + return flash_ids[i].size * 1024;
> +
> + dev_err(dev, "Unknown flash id (%08x)\n", id);
> + return 0;
> +}
And this.
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/2a635469/attachment.sig>
^ permalink raw reply
* [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
From: James Bottomley @ 2013-01-17 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117110438.GZ23505@n2100.arm.linux.org.uk>
On Thu, 2013-01-17 at 11:04 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 17, 2013 at 11:01:47AM +0000, James Bottomley wrote:
> > On Thu, 2013-01-17 at 10:47 +0000, Russell King - ARM Linux wrote:
> > > Also, couldn't the addition of the scatterlist offset to the page also
> > > be buggy too?
> >
> > No, fortunately, offset must be within the first page from the point of
> > view of block generated sg lists. As long as nothing within arm
> > violates this, it should be a safe assumption ... although the code
> > seems to assume otherwise.
>
> Are you absolutely sure about that? I believe I have seen cases where
> that has been violated in the past, though it was many years ago.
>From the point of view of the block layer, absolutely: the scatterlist
is generated from an array of bio_vecs. Each bio_vec is a page, offset
and length element and obeys the rule that offset must be within the
page and offset + length cannot stray over the page.
>From the point of view of other arm stuff, I don't know.
James
^ permalink raw reply
* [PATCH 0/4] gpio: introduce descriptor-based interface
From: Linus Walleij @ 2013-01-17 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301101008.45091.arnd@arndb.de>
On Thu, Jan 10, 2013 at 11:08 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> I've tried to find platforms that don't yet use GPIOLIB and fortunately
> there are very few left:
>
> I found two that provide the generic gpio interfaces when gpiolib
> is disabled, but use gpiolib otherwise for the same hardware,
> arch/m68k/include/asm/mcfgpio.h and arch/blackfin/include/asm/gpio.h.
> I would assume that we can simply remove the non-gpiolib shortcut
> here at cost of a small overhead.
Geert/Greg: interested in looking into this issue?
The GPIO maintainers want to get rid of non-gpiolib platforms.
Yours,
Linus Walleij
^ permalink raw reply
* [RFC PATCH 1/6] usb: otg: Add an API to bind the USB controller and PHY
From: kishon @ 2013-01-17 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7C643.600@ti.com>
Hi,
On Thursday 17 January 2013 03:07 PM, Roger Quadros wrote:
> On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
>> New platforms are added which has multiple PHY's (of same type) and
>> which has multiple USB controllers. The binding information has to be
>> present in the PHY library (otg.c) in order for it to return the
>> appropriate PHY whenever the USB controller request for the PHY. So
>> added a new API to pass the binding information. This API should be
>> called by platform specific initialization code.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> drivers/usb/otg/otg.c | 37 +++++++++++++++++++++++++++++++++++++
>> include/linux/usb/phy.h | 22 ++++++++++++++++++++++
>> 2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/usb/otg/otg.c b/drivers/usb/otg/otg.c
>> index a30c041..492ba2f 100644
>> --- a/drivers/usb/otg/otg.c
>> +++ b/drivers/usb/otg/otg.c
>> @@ -18,6 +18,7 @@
>> #include <linux/usb/otg.h>
>>
>> static LIST_HEAD(phy_list);
>> +static LIST_HEAD(phy_bind_list);
>> static DEFINE_SPINLOCK(phy_lock);
>>
>> static struct usb_phy *__usb_find_phy(struct list_head *list,
>> @@ -201,6 +202,42 @@ void usb_remove_phy(struct usb_phy *x)
>> }
>> EXPORT_SYMBOL(usb_remove_phy);
>>
>> +/**
>> + * usb_bind_phy - bind the phy and the controller that uses the phy
>> + * @dev_name: the device name of the device that will bind to the phy
>> + * @index: index to specify the port number
>> + * @phy_dev_name: the device name of the phy
>> + *
>> + * Fills the phy_bind structure with the dev_name and phy_dev_name. This will
>> + * be used when the phy driver registers the phy and when the controller
>> + * requests this phy.
>> + *
>> + * To be used by platform specific initialization code.
>> + */
>> +struct usb_phy_bind __init *usb_bind_phy(const char *dev_name, u8 index,
>> + const char *phy_dev_name)
>> +{
>> + struct usb_phy_bind *phy_bind;
>> + unsigned long flags;
>> +
>> + phy_bind = kzalloc(sizeof(*phy_bind), GFP_KERNEL);
>> + if (!phy_bind) {
>> + pr_err("phy_bind(): No memory for phy_bind");
>
> Function name in comment doesn't match the actual.
> Instead, you could use
> pr_err("%s ...", __func__);
>
>> + return ERR_PTR(-ENOMEM);
>> + }
>> +
>> + phy_bind->dev_name = dev_name;
>> + phy_bind->phy_dev_name = phy_dev_name;
>> + phy_bind->index = index;
>> +
>> + spin_lock_irqsave(&phy_lock, flags);
>> + list_add_tail(&phy_bind->list, &phy_bind_list);
>> + spin_unlock_irqrestore(&phy_lock, flags);
>> +
>> + return phy_bind;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_bind_phy);
>> +
>> const char *otg_state_string(enum usb_otg_state state)
>> {
>> switch (state) {
>> diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
>> index a29ae1e..fbeab1a 100644
>> --- a/include/linux/usb/phy.h
>> +++ b/include/linux/usb/phy.h
>> @@ -106,6 +106,21 @@ struct usb_phy {
>> enum usb_device_speed speed);
>> };
>>
>> +/**
>> + * struct usb_phy_bind - represent the binding for the phy
>> + * @dev_name: the device name of the device that will bind to the phy
>> + * @phy_dev_name: the device name of the phy
>> + * @index: used if a single controller uses multiple phys
>> + * @phy: reference to the phy
>> + * @list: to maintain a linked list of the binding information
>> + */
>> +struct usb_phy_bind {
>> + const char *dev_name;
>> + const char *phy_dev_name;
>> + u8 index;
>> + struct usb_phy *phy;
>> + struct list_head list;
>> +};
>>
>> /* for board-specific init logic */
>> extern int usb_add_phy(struct usb_phy *, enum usb_phy_type type);
>> @@ -151,6 +166,8 @@ extern struct usb_phy *devm_usb_get_phy(struct device *dev,
>> enum usb_phy_type type);
>> extern void usb_put_phy(struct usb_phy *);
>> extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
>> +extern struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
>> + const char *phy_dev_name);
>> #else
>> static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
>> {
>> @@ -171,6 +188,11 @@ static inline void devm_usb_put_phy(struct device *dev, struct usb_phy *x)
>> {
>> }
>>
>> +static inline struct usb_phy_bind *usb_bind_phy(const char *dev_name, u8 index,
>> + const char *phy_dev_name)
>> +{
>> + return NULL;
>> +}
>> #endif
>>
>> static inline int
>>
>
> Controllers like ehci-omap which don't need OTG functionality would
> benefit from this API. Can we make these PHY APIs not dependent on OTG /
> OTG_UTILS?
Actually much of whatever is in otg.c can be used by controllers which
don't have OTG functionality (except otg_state_string). I vaguely
remember, there was a patch that renamed otg.c to phy.c etc.. I'm not
sure what happened to that.
Thanks
Kishon
^ permalink raw reply
* [PATCH v6 1/3] usb: fsl-mxc-udc: replace cpu_is_xxx() with platform_device_id
From: Fabio Estevam @ 2013-01-17 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358416874-27011-2-git-send-email-peter.chen@freescale.com>
On Thu, Jan 17, 2013 at 8:01 AM, Peter Chen <peter.chen@freescale.com> wrote:
> /* make sure USB_CLK is running at 60 MHz +/- 1000 Hz */
> - if (!cpu_is_mx51()) {
> + if (!strcmp(pdev->id_entry->name, "imx-udc-mx27")) {]]
Shouldn't this be:
if (!strcmp(pdev->id_entry->name, "imx-udc-mx51"))
^ permalink raw reply
* [PATCH 1/2] ARM: sunxi: gpio: Add Allwinner SoCs GPIO drivers
From: Linus Walleij @ 2013-01-17 11:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F127A4.907@free-electrons.com>
On Sat, Jan 12, 2013 at 10:06 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
>> Use gpiochip_add_pin_range() from the GPIO driver.
>>
>> An example is provided in
>> drivers/pinctrl/pinctrl-coh901.c
>
> Ok, will do. But we need to find a way to share the pins arrays between
> the pinctrl and gpio drivers then.
>
> Maybe add a pinctrl-sunxi-pins.h file? or merge the pinctrl and gpio
> drivers?
>
> I'm kind of reluctant to merging the drivers into one single messy file,
> but if that's the way to go, fine.
Well, does it have to be that messy?
You can merge it different ways.
For example there is *no* need to have two different device driver
structs and two probe functions, right?
Just one device named pinctrl that has one state container and
one single dd and probe function. That makes everything sooo
much easier I think.
Just register both a pinctrl and GPIO interface (in that order).
See the recent pinctrl-abx500.c submission for an example on
how to do this.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
From: Russell King - ARM Linux @ 2013-01-17 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358420507.2394.19.camel@dabdike.int.hansenpartnership.com>
On Thu, Jan 17, 2013 at 11:01:47AM +0000, James Bottomley wrote:
> On Thu, 2013-01-17 at 10:47 +0000, Russell King - ARM Linux wrote:
> > Also, couldn't the addition of the scatterlist offset to the page also
> > be buggy too?
>
> No, fortunately, offset must be within the first page from the point of
> view of block generated sg lists. As long as nothing within arm
> violates this, it should be a safe assumption ... although the code
> seems to assume otherwise.
Are you absolutely sure about that? I believe I have seen cases where
that has been violated in the past, though it was many years ago.
^ permalink raw reply
* [RFC PATCH 2/6] ARM: OMAP: USB: Add phy binding information
From: kishon @ 2013-01-17 11:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7C6C7.3030400@ti.com>
Hi,
On Thursday 17 January 2013 03:09 PM, Roger Quadros wrote:
> On 01/16/2013 05:00 PM, Kishon Vijay Abraham I wrote:
>> This is in preparation for the changes in PHY library to support adding
>> and getting multiple PHYs of the same type. In the new design, the
>> binding information between the PHY and the USB controller should be
>> specified in the platform specific initialization code. So it's been
>> done for OMAP platforms here.
>>
>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>> ---
>> This kind-of binding should be done in all the platforms (I've done only
>> for OMAP platform).
>> arch/arm/mach-omap2/usb-musb.c | 7 ++++++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
>> index 9d27e3f..bbe2fa5 100644
>> --- a/arch/arm/mach-omap2/usb-musb.c
>> +++ b/arch/arm/mach-omap2/usb-musb.c
>> @@ -24,6 +24,7 @@
>> #include <linux/dma-mapping.h>
>> #include <linux/io.h>
>> #include <linux/usb/musb.h>
>> +#include <linux/usb/phy.h>
>>
>> #include "omap_device.h"
>> #include "soc.h"
>> @@ -85,8 +86,12 @@ void __init usb_musb_init(struct omap_musb_board_data *musb_board_data)
>> musb_plat.mode = board_data->mode;
>> musb_plat.extvbus = board_data->extvbus;
>>
>> - if (cpu_is_omap44xx())
>> + if (cpu_is_omap44xx()) {
>> musb_plat.has_mailbox = true;
>> + usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
>> + } else if (cpu_is_omap34xx()) {
>> + usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
>> + }
>
> Are you sure than these OMAP platforms cannot be wired in any other way
> to the PHY?
>
> If they can be then this association must come from the board files or
> device tree.
I had given some thought about that and since all the existing OMAP
platforms had it this way, I added it here.
You having pointed that out, I'll move these to board files.
Thanks
Kishon
^ permalink raw reply
* [PATCH v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
From: James Bottomley @ 2013-01-17 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117104741.GY23505@n2100.arm.linux.org.uk>
On Thu, 2013-01-17 at 10:47 +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 17, 2013 at 10:37:42AM +0000, Russell King - ARM Linux wrote:
> > On Thu, Jan 17, 2013 at 09:11:20AM +0000, James Bottomley wrote:
> > > I'd actually prefer page = pfn_to_page(page_to_pfn(page) + 1); because
> > > it makes the code look like the hack it is. The preferred form for all
> > > iterators like this should be to iterate over the pfn instead of a
> > > pointer into the page arrays, because that will always work correctly no
> > > matter how many weird and wonderful memory schemes we come up with.
> >
> > So, why don't we update the code to do that then?
We can, but it involves quite a rewrite within the arm dma-mapping code
to use pfn instead of page. It looks like it would make the code
cleaner because there are a lot of page_to_pfn transformations in there.
However, the current patch is the simplest one for stable and I don't
actually have any arm build and test environments.
> Also, couldn't the addition of the scatterlist offset to the page also
> be buggy too?
No, fortunately, offset must be within the first page from the point of
view of block generated sg lists. As long as nothing within arm
violates this, it should be a safe assumption ... although the code
seems to assume otherwise.
James
> So, what about this patch which addresses both additions by keeping our
> iterator as a pfn as you suggest. It also simplifies some of the code
> in the loop too.
>
> Can the original folk with the problem test this patch?
>
> arch/arm/mm/dma-mapping.c | 18 ++++++++++--------
> 1 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index 6b2fb87..076c26d 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -774,25 +774,27 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
> size_t size, enum dma_data_direction dir,
> void (*op)(const void *, size_t, int))
> {
> + unsigned long pfn;
> + size_t left = size;
> +
> + pfn = page_to_pfn(page) + offset / PAGE_SIZE;
> + offset %= PAGE_SIZE;
> +
> /*
> * A single sg entry may refer to multiple physically contiguous
> * pages. But we still need to process highmem pages individually.
> * If highmem is not configured then the bulk of this loop gets
> * optimized out.
> */
> - size_t left = size;
> do {
> size_t len = left;
> void *vaddr;
>
> + page = pfn_to_page(pfn);
> +
> if (PageHighMem(page)) {
> - if (len + offset > PAGE_SIZE) {
> - if (offset >= PAGE_SIZE) {
> - page += offset / PAGE_SIZE;
> - offset %= PAGE_SIZE;
> - }
> + if (len + offset > PAGE_SIZE)
> len = PAGE_SIZE - offset;
> - }
> vaddr = kmap_high_get(page);
> if (vaddr) {
> vaddr += offset;
> @@ -809,7 +811,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
> op(vaddr, len, dir);
> }
> offset = 0;
> - page++;
> + pfn++;
> left -= len;
> } while (left);
> }
Looks reasonable modulo all the simplification we could do if we can
assume offset < PAGE_SIZE
James
^ permalink raw reply
* [PATCH v6 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc
From: Shawn Guo @ 2013-01-17 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117105833.GP10814@arwen.pp.htv.fi>
On Thu, Jan 17, 2013 at 12:58:33PM +0200, Felipe Balbi wrote:
> On Thu, Jan 17, 2013 at 06:03:17PM +0800, Peter Chen wrote:
> > As we use platform_device_id for fsl-usb2-udc driver, it needs to
> > change clk connection-id, or the related devm_clk_get will be failed.
> >
> > Signed-off-by: Peter Chen <peter.chen@freescale.com>
>
> do I get Acked-by for this one ?
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* [V3 PATCH 11/25] arm: mmp2: change the defintion of usb devices
From: Felipe Balbi @ 2013-01-17 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN1soZzH8OPR=KLS+c5M_Ttme4XNhW6Pzz-gbPngSwo6+jXwMA@mail.gmail.com>
Hi,
On Thu, Jan 17, 2013 at 05:59:20PM +0800, Haojian Zhuang wrote:
> On Thu, Jan 17, 2013 at 5:12 PM, Felipe Balbi <balbi@ti.com> wrote:
> > On Tue, Jan 15, 2013 at 01:19:04AM -0500, Chao Xie wrote:
> >> add the udc/otg/ehci devices for mmp2
> >>
> >> Signed-off-by: Chao Xie <chao.xie@marvell.com>
> >
> > Haojian, can I get an Acked-by for this patch or will you carry it
> > yourself ?
> >
> > Likewise for all other arch/arm/* patches in this series
> >
> > --
> > balbi
>
> Sure. You can apply these patches.
>
> Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Thank you
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/95701620/attachment-0001.sig>
^ permalink raw reply
* [PATCH v6 3/3] ARM: i.MX clock: Change the connection-id for fsl-usb2-udc
From: Felipe Balbi @ 2013-01-17 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358416997-29099-4-git-send-email-peter.chen@freescale.com>
On Thu, Jan 17, 2013 at 06:03:17PM +0800, Peter Chen wrote:
> As we use platform_device_id for fsl-usb2-udc driver, it needs to
> change clk connection-id, or the related devm_clk_get will be failed.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
do I get Acked-by for this one ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/0e2bdba7/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: ux500: Include the PRCMU's Secure Registers in DB8500's DT
From: Linus Walleij @ 2013-01-17 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357901029-9073-1-git-send-email-lee.jones@linaro.org>
On Fri, Jan 11, 2013 at 11:43 AM, Lee Jones <lee.jones@linaro.org> wrote:
> Currently we only include the PRCMU's primary registers when
> referencing the register count in the 'reg' property. This patch
> expands that count to include the secure registers also.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Will you push this to ARM SoC or shall I queue it?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] ARM: imx: select HAVE_IMX_SRC when SMP is enabled
From: Shawn Guo @ 2013-01-17 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358419936.2731.221.camel@sauron.fi.intel.com>
On Thu, Jan 17, 2013 at 12:52:16PM +0200, Artem Bityutskiy wrote:
> Err, sorry, the issue I get is a bit different, but similar:
>
> arch/arm/mach-imx/built-in.o: In function `imx6q_restart':
> platform-spi_imx.c:(.text+0x2220): undefined reference to `imx_src_prepare_restart'
> arch/arm/mach-imx/built-in.o: In function `imx6q_pm_enter':
> platform-spi_imx.c:(.text+0x22e4): undefined reference to `imx_set_cpu_jump'
> arch/arm/mach-imx/built-in.o: In function `imx6q_init_irq':
> platform-spi_imx.c:(.init.text+0x7280): undefined reference to `imx_src_init'
> make[1]: *** [vmlinux] Error 1
>
The fix [1] is on the way to mainline.
Shawn
[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/209206
^ permalink raw reply
* CoreSight framework and drivers
From: Will Deacon @ 2013-01-17 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116001458.GB7013@pratikp-linux.qualcomm.com>
On Wed, Jan 16, 2013 at 12:14:59AM +0000, Pratik Patel wrote:
> On Mon, Jan 07, 2013 at 11:58:36AM +0000, Will Deacon wrote:
> > On Thu, Jan 03, 2013 at 06:06:43PM +0000, Pratik Patel wrote:
> > > Whats the advantage in using debugfs here?
> >
> > The main things I like about debugfs are (a) it's a text-driven interface
> > and easy to script with and (b) it matches what we do for ftrace.
> >
> > Furthermore, it means that subtle differences between devices can be hidden
> > in the driver and not require different vendor tools for parsing the trace
> > data.
> >
> Sorry for the delay and maybe I am missing something but it seems
> we can take care of such protocol or parsing/decoding differences
> even with device nodes since that seems independent of the
> interface used - per device debugfs attributes or per device
> device nodes.
You seem to be arguing that the two interfaces are equivalent, in which case
I say that we should follow ftrace's lead and use debugfs for this...
...but I still maintain that debugfs is also far easier to work with from
userspace.
> CoreSight trace solution is typically a SoC wide solution and
> hence can get used by non-Linux processors or hardware. Using
> debugfs would imply compiling it and exposing all the debug
> knobs even if the use case was to use the CoreSight solution for
> something that didn't need all that.
Many debug features require debugfs to be compiled, so I don't buy that as a
show-stopping argument in favour of using dev nodes. I also think that exposing
all of the debug knobs is actually a good thing, given the low-level nature of
coresight devices (where we're offloading most of the knowledge to userspace
anyway).
Will
^ permalink raw reply
* [PATCH] ARM: imx: select HAVE_IMX_SRC when SMP is enabled
From: Artem Bityutskiy @ 2013-01-17 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350977942-15964-1-git-send-email-shawn.guo@linaro.org>
On Tue, 2012-10-23 at 15:39 +0800, Shawn Guo wrote:
> With being part of multi-platform support, SMP can be enabled by other
> platform even when SOC_IMX6Q is deselected. It leads to a situation
> that arch/arm/mach-imx/platsmp.c is built without HAVE_IMX_SRC selection
> which will cause build error. For example, the following link errors
> will be seen when building imx5 with other v7 platforms.
>
> arch/arm/mach-imx/built-in.o: In function `imx_cpu_die':
> platform-ahci-imx.c:(.text+0x219c): undefined reference to `imx_enable_cpu'
> arch/arm/mach-imx/built-in.o: In function `imx_boot_secondary':
> platform-ahci-imx.c:(.cpuinit.text+0x14): undefined reference to `imx_set_cpu_jump'
> platform-ahci-imx.c:(.cpuinit.text+0x20): undefined reference to `imx_enable_cpu'
>
> Select HAVE_IMX_SRC as long as SMP is enabled to fix the problem.
Err, sorry, the issue I get is a bit different, but similar:
arch/arm/mach-imx/built-in.o: In function `imx6q_restart':
platform-spi_imx.c:(.text+0x2220): undefined reference to `imx_src_prepare_restart'
arch/arm/mach-imx/built-in.o: In function `imx6q_pm_enter':
platform-spi_imx.c:(.text+0x22e4): undefined reference to `imx_set_cpu_jump'
arch/arm/mach-imx/built-in.o: In function `imx6q_init_irq':
platform-spi_imx.c:(.init.text+0x7280): undefined reference to `imx_src_init'
make[1]: *** [vmlinux] Error 1
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/faaeebf8/attachment-0001.sig>
^ permalink raw reply
* [PATCH] usb: musb: ux500: use clk_prepare_enable and clk_disable_unprepare
From: Felipe Balbi @ 2013-01-17 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbmgQ0xDfkbgqc=zDqMDUK0O6uQOf3kX9v1+=+N5s42bw@mail.gmail.com>
On Thu, Jan 17, 2013 at 11:46:30AM +0100, Linus Walleij wrote:
> On Thu, Jan 10, 2013 at 2:38 PM, Fabio Baltieri
> <fabio.baltieri@linaro.org> wrote:
> > On Thu, Jan 10, 2013 at 12:23:32PM +0100, Linus Walleij wrote:
> >> On Mon, Jan 7, 2013 at 5:47 PM, Fabio Baltieri
> >> <fabio.baltieri@linaro.org> wrote:
> >>
> >> > This patch converts the module to use clk_prepare_enable and
> >> > clk_disable_unprepare variants as required by common clock framework.
> >> >
> >> > Without this the system crash during probe function.
> >> >
> >> > Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
> >>
> >> Acked-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > Thanks for the ACK. This bug was here unnoticed since 3.6 merge window,
>
> Then it should have Cc: stable at kernel.org..
just added to my tree.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/c7c4d190/attachment.sig>
^ permalink raw reply
* [PATCH 01/26] gpio: samsung: remove inclusion <mach/regs-clock.h>
From: Linus Walleij @ 2013-01-17 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <027701cdef62$12363bb0$36a2b310$@samsung.com>
On Thu, Jan 10, 2013 at 7:41 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> BTW, do you have any comments on following patches?
>
> [PATCH] gpio: samsung: silent build warning for EXYNOS5
> http://www.mail-archive.com/linux-samsung-soc at vger.kernel.org/msg14443.html
Merged to fixes.
> [PATCH] gpio: samsung: fix pinctrl condition for exynos and exynos5440
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/14758
Merged to fixes.
> [PATCH] gpio: samsung: skip gpio lib registration for EXYNOS5440
> http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/14673
I'll check it out, may have missed it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Arnd Bergmann @ 2013-01-17 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F61D86.4020801@web.de>
On Wednesday 16 January 2013, Soeren Moch wrote:
> >> I will see what I can do here. Is there an easy way to track the buffer
> >> usage without having to wait for complete exhaustion?
> >
> > DMA_API_DEBUG
>
> OK, maybe I can try this.
> >
Any success with this? It should at least tell you if there is a
memory leak in one of the drivers.
Arnd
^ permalink raw reply
* [PATCH] ARM: imx: select HAVE_IMX_SRC when SMP is enabled
From: Artem Bityutskiy @ 2013-01-17 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350977942-15964-1-git-send-email-shawn.guo@linaro.org>
On Tue, 2012-10-23 at 15:39 +0800, Shawn Guo wrote:
> With being part of multi-platform support, SMP can be enabled by other
> platform even when SOC_IMX6Q is deselected. It leads to a situation
> that arch/arm/mach-imx/platsmp.c is built without HAVE_IMX_SRC selection
> which will cause build error. For example, the following link errors
> will be seen when building imx5 with other v7 platforms.
>
> arch/arm/mach-imx/built-in.o: In function `imx_cpu_die':
> platform-ahci-imx.c:(.text+0x219c): undefined reference to `imx_enable_cpu'
> arch/arm/mach-imx/built-in.o: In function `imx_boot_secondary':
> platform-ahci-imx.c:(.cpuinit.text+0x14): undefined reference to `imx_set_cpu_jump'
> platform-ahci-imx.c:(.cpuinit.text+0x20): undefined reference to `imx_enable_cpu'
>
> Select HAVE_IMX_SRC as long as SMP is enabled to fix the problem.
>
> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
The build is still broken in Linus' tree...
--
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/91f7f5e2/attachment.sig>
^ permalink raw reply
* [PATCH 4/4 v3] net/smsc911x: Provide common clock functionality
From: Lee Jones @ 2013-01-17 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY+C8jNT7LsJvBkauN4+x4k4gGJKSe0ynY_HLTpmpgFPA@mail.gmail.com>
> >> > Some platforms provide clocks which require enabling before the
> >> > SMSC911x chip will power on. This patch uses the new common clk
> >> > framework to do just that. If no clock is provided, it will just
> >> > be ignored and the driver will continue to assume that no clock
> >> > is required for the chip to run successfully.
> >> >
> >> > Cc: Steve Glendinning <steve.glendinning@shawell.net>
> >> > Cc: netdev at vger.kernel.org
> >> > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> >>
> >> Looks all right to me now:
> >> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> >
> > I still need a maintiner Ack for this before I can push it.
> >
> > Anyone?
>
> Steve is there sometimes. But I'd ask David Miller to ACK
> it if he's OK with the change.
>
> Yours,
> Linus Walleij
Hi David,
Does this [1] patch look okay to you too?
It's the last Ack I require before I can push the set.
[1] https://patchwork.kernel.org/patch/1926971/
--
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 v2 1/1] block: blk-merge: don't merge the pages with non-contiguous descriptors
From: Russell King - ARM Linux @ 2013-01-17 10:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117103742.GX23505@n2100.arm.linux.org.uk>
On Thu, Jan 17, 2013 at 10:37:42AM +0000, Russell King - ARM Linux wrote:
> On Thu, Jan 17, 2013 at 09:11:20AM +0000, James Bottomley wrote:
> > I'd actually prefer page = pfn_to_page(page_to_pfn(page) + 1); because
> > it makes the code look like the hack it is. The preferred form for all
> > iterators like this should be to iterate over the pfn instead of a
> > pointer into the page arrays, because that will always work correctly no
> > matter how many weird and wonderful memory schemes we come up with.
>
> So, why don't we update the code to do that then?
Also, couldn't the addition of the scatterlist offset to the page also
be buggy too?
So, what about this patch which addresses both additions by keeping our
iterator as a pfn as you suggest. It also simplifies some of the code
in the loop too.
Can the original folk with the problem test this patch?
arch/arm/mm/dma-mapping.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..076c26d 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -774,25 +774,27 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
size_t size, enum dma_data_direction dir,
void (*op)(const void *, size_t, int))
{
+ unsigned long pfn;
+ size_t left = size;
+
+ pfn = page_to_pfn(page) + offset / PAGE_SIZE;
+ offset %= PAGE_SIZE;
+
/*
* A single sg entry may refer to multiple physically contiguous
* pages. But we still need to process highmem pages individually.
* If highmem is not configured then the bulk of this loop gets
* optimized out.
*/
- size_t left = size;
do {
size_t len = left;
void *vaddr;
+ page = pfn_to_page(pfn);
+
if (PageHighMem(page)) {
- if (len + offset > PAGE_SIZE) {
- if (offset >= PAGE_SIZE) {
- page += offset / PAGE_SIZE;
- offset %= PAGE_SIZE;
- }
+ if (len + offset > PAGE_SIZE)
len = PAGE_SIZE - offset;
- }
vaddr = kmap_high_get(page);
if (vaddr) {
vaddr += offset;
@@ -809,7 +811,7 @@ static void dma_cache_maint_page(struct page *page, unsigned long offset,
op(vaddr, len, dir);
}
offset = 0;
- page++;
+ pfn++;
left -= len;
} while (left);
}
^ permalink raw reply related
* [PATCH] usb: musb: ux500: use clk_prepare_enable and clk_disable_unprepare
From: Linus Walleij @ 2013-01-17 10:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130110133818.GA22710@balto.lan>
On Thu, Jan 10, 2013 at 2:38 PM, Fabio Baltieri
<fabio.baltieri@linaro.org> wrote:
> On Thu, Jan 10, 2013 at 12:23:32PM +0100, Linus Walleij wrote:
>> On Mon, Jan 7, 2013 at 5:47 PM, Fabio Baltieri
>> <fabio.baltieri@linaro.org> wrote:
>>
>> > This patch converts the module to use clk_prepare_enable and
>> > clk_disable_unprepare variants as required by common clock framework.
>> >
>> > Without this the system crash during probe function.
>> >
>> > Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
>>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> Thanks for the ACK. This bug was here unnoticed since 3.6 merge window,
Then it should have Cc: stable at kernel.org..
> do you think it may make sense to add this driver to u8500_defconfig? I
> can send a patch if you say so...
Yes, can you make a patch updating the defconfig and also enabling
a few other things like charging maybe? Sync with Lee.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 6/7] ARM i.MX5: Add System Reset Controller (SRC) support for i.MX51 and i.MX53
From: Philipp Zabel @ 2013-01-17 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117061200.GK26179@S2101-09.ap.freescale.net>
Hi Shawn,
thank you for your comments.
Am Donnerstag, den 17.01.2013, 14:12 +0800 schrieb Shawn Guo:
> On Wed, Jan 16, 2013 at 05:13:06PM +0100, Philipp Zabel wrote:
> > The SRC in i.MX51 and i.MX53 is similar to the one in i.MX6q minus
> > the IPU2 reset line and multi core CPU reset/enable bits.
> >
> > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > ---
> > arch/arm/mach-imx/Kconfig | 1 +
> > arch/arm/mach-imx/common.h | 3 ++-
> > arch/arm/mach-imx/mach-imx6q.c | 2 +-
> > arch/arm/mach-imx/mm-imx5.c | 2 ++
> > arch/arm/mach-imx/src.c | 14 +++++++++++++-
> > 5 files changed, 19 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > index 3e628fd..d7924e5 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -829,6 +829,7 @@ config SOC_IMX53
> > select ARCH_MX53
> > select HAVE_CAN_FLEXCAN if CAN
> > select IMX_HAVE_PLATFORM_IMX2_WDT
> > + select HAVE_IMX_SRC
>
> Please sort it in name. Should we manage to have it selected for imx51
> too, since you have code added for imx51 below?
Yes, I'll add that.
> > select PINCTRL
> > select PINCTRL_IMX53
> > select SOC_IMX5
> > diff --git a/arch/arm/mach-imx/common.h b/arch/arm/mach-imx/common.h
> > index 7191ab4..f36be3c 100644
> > --- a/arch/arm/mach-imx/common.h
> > +++ b/arch/arm/mach-imx/common.h
> > @@ -133,7 +133,8 @@ static inline void imx_smp_prepare(void) {}
> > #endif
> > extern void imx_enable_cpu(int cpu, bool enable);
> > extern void imx_set_cpu_jump(int cpu, void *jump_addr);
> > -extern void imx_src_init(void);
> > +extern void imx5_src_init(void);
> > +extern void imx6q_src_init(void);
> > extern void imx_src_prepare_restart(void);
> > extern void imx_gpc_init(void);
> > extern void imx_gpc_pre_suspend(void);
> > diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> > index cd277a0..b1e076c 100644
> > --- a/arch/arm/mach-imx/mach-imx6q.c
> > +++ b/arch/arm/mach-imx/mach-imx6q.c
> > @@ -229,7 +229,7 @@ static const struct of_device_id imx6q_irq_match[] __initconst = {
> > static void __init imx6q_init_irq(void)
> > {
> > l2x0_of_init(0, ~0UL);
> > - imx_src_init();
> > + imx6q_src_init();
>
> I'm not sure this is necessary. See below ...
>
> > imx_gpc_init();
> > of_irq_init(imx6q_irq_match);
> > }
> > diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
> > index 79d71cf..53f87be 100644
> > --- a/arch/arm/mach-imx/mm-imx5.c
> > +++ b/arch/arm/mach-imx/mm-imx5.c
> > @@ -106,6 +106,7 @@ void __init imx51_init_early(void)
> > mxc_set_cpu_type(MXC_CPU_MX51);
> > mxc_iomux_v3_init(MX51_IO_ADDRESS(MX51_IOMUXC_BASE_ADDR));
> > mxc_arch_reset_init(MX51_IO_ADDRESS(MX51_WDOG1_BASE_ADDR));
> > + imx5_src_init();
> > }
> >
> > void __init imx53_init_early(void)
> > @@ -113,6 +114,7 @@ void __init imx53_init_early(void)
> > mxc_set_cpu_type(MXC_CPU_MX53);
> > mxc_iomux_v3_init(MX53_IO_ADDRESS(MX53_IOMUXC_BASE_ADDR));
> > mxc_arch_reset_init(MX53_IO_ADDRESS(MX53_WDOG1_BASE_ADDR));
> > + imx5_src_init();
> > }
> >
> > void __init mx50_init_irq(void)
> > diff --git a/arch/arm/mach-imx/src.c b/arch/arm/mach-imx/src.c
> > index 41687c6..e350250 100644
> > --- a/arch/arm/mach-imx/src.c
> > +++ b/arch/arm/mach-imx/src.c
> > @@ -125,7 +125,19 @@ void imx_src_prepare_restart(void)
> > writel_relaxed(0, src_base + SRC_GPR1);
> > }
> >
> > -void __init imx_src_init(void)
> > +void __init imx5_src_init(void)
> > +{
> > + struct device_node *np;
> > +
> > + np = of_find_compatible_node(NULL, NULL, "fsl,imx5-src");
>
> In fsl,imx-src.txt, we have
>
> compatible: Should be "fsl,<chip>-src"
>
> But imx5 is not a chip name. I would suggest we have the imx-src driver
> only look for compatible "fsl,imx51-src", and for dts
>
> imx51: compatible = "fsl,imx51-src";
> imx53: compatible = "fsl,imx53-src", "fsl,imx51-src";
> imx6q: compatible = "fsl,imx6q-src", "fsl,imx51-src";
>
> so that we do not need imx5_src_init and imx6q_src_init which are
> basically doing the same thing.
So we should unconditionally clear the BP_SRC_SCR_WARM_RESET_ENABLE bit
on i.MX5, too? I'll try that.
> > + src_base = of_iomap(np, 0);
> > + WARN_ON(!src_base);
>
> As imx51 still supports non-DT boot, we should have a check on np.
> If np is NULL, mostly likely it's a non-DT boot on imx51, and we
> should bail out instead of giving a fat warning.
Ok. I'll apply this and the comments from your other mails before
sending the next version.
regards
Philipp
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox