* [PATCH V3 0/3] Add clock framework for armada 370/XP
From: Gregory CLEMENT @ 2012-10-21 12:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017153925.GR20922@titan.lakedaemon.net>
On 10/17/2012 05:39 PM, Jason Cooper wrote:
> Mike,
>
> On Mon, Oct 15, 2012 at 02:18:16PM +0200, Gregory CLEMENT wrote:
>> Hello Mike,
>>
>> The v3.7-rc1 was released yesterday. So here it is the updated version
>> of my patch set. The rebase was flawless. An I have just fixed a typo
>> in the device tree and warnings from checkpatch. I built and test it
>> for the Armada 370 and Armada XP evaluation board.
>>
>> The purpose of this patch set is to add support for clock framework
>> for Armada 370 and Armada XP SoCs. All the support is done under the
>> directory drivers/clk/mvebu/ as the support for other mvebu SoCs was
>> in mind during the writing of the code.
>>
>> Two kinds of clocks are added:
>>
>> - The CPU clocks are only for Armada XP (which is multi-core)
>>
>> - The core clocks are clocks which have their rate fixed during
>> reset.
>>
>> Many thanks to Thomas Petazzoni and Sebastian Hesselbarth for their
>> review and feedback. The device tree bindings were really improved
>> with the advices of Sebastian.
>>
>> Changelog:
>> V2 -> V3:
>> - Rebased on top of v3.7-rc1
>> - Fixed a typo in device trees
>> - Fixed warning from checkpatch
>>
>> V1 -> V2:
>>
>> - Improved the spelling and the wording of the documentation and the
>> 1st commit log
>> - Removed the "end_of_list" name which are unused here.
>> - Fix the cpu clock by using of_clk_src_onecell_get in the same way it
>> was used for the core clocks
>>
>> Regards,
>>
>>
>> Gregory CLEMENT (3):
>> clk: mvebu: add armada-370-xp specific clocks
>> clk: armada-370-xp: add support for clock framework
>> clocksource: time-armada-370-xp converted to clk framework
>>
>> .../devicetree/bindings/clock/mvebu-core-clock.txt | 40 +++
>> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 21 ++
>> arch/arm/boot/dts/armada-370-db.dts | 4 -
>> arch/arm/boot/dts/armada-370-xp.dtsi | 1 +
>> arch/arm/boot/dts/armada-370.dtsi | 12 +
>> arch/arm/boot/dts/armada-xp.dtsi | 48 +++
>> arch/arm/mach-mvebu/Kconfig | 5 +
>> arch/arm/mach-mvebu/armada-370-xp.c | 8 +-
>> arch/arm/mach-mvebu/common.h | 1 +
>> drivers/clk/Makefile | 1 +
>> drivers/clk/mvebu/Makefile | 2 +
>> drivers/clk/mvebu/clk-core.c | 312 ++++++++++++++++++++
>> drivers/clk/mvebu/clk-core.h | 19 ++
>> drivers/clk/mvebu/clk-cpu.c | 155 ++++++++++
>> drivers/clk/mvebu/clk-cpu.h | 19 ++
>> drivers/clk/mvebu/clk.c | 36 +++
>> drivers/clocksource/time-armada-370-xp.c | 11 +-
>> 17 files changed, 685 insertions(+), 10 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
>> create mode 100644 Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
>> create mode 100644 drivers/clk/mvebu/Makefile
>> create mode 100644 drivers/clk/mvebu/clk-core.c
>> create mode 100644 drivers/clk/mvebu/clk-core.h
>> create mode 100644 drivers/clk/mvebu/clk-cpu.c
>> create mode 100644 drivers/clk/mvebu/clk-cpu.h
>> create mode 100644 drivers/clk/mvebu/clk.c
>
> Would it be okay if we took this through the mvebu tree? It looks like
> the only potential merge conflict we would have would be in
> drivers/clk/Makefile. It would make dependency tracking easier.
>
It will also be easier for me if it was possible, because I have
patch series awaiting which will depend on the support of the
clock framework for mvebu.
> Otherwise is fine as well, just let me know which you prefer.
>
> Assuming, of course, everything looks good to you.
>
> thx,
>
> Jason.
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Artem Bityutskiy @ 2012-10-21 12:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350817204.1704.0.camel@kyv>
On Sun, 2012-10-21 at 14:00 +0300, Artem Bityutskiy wrote:
> > > I'm mainly thinking of blk_rq_map_sg()
> > > from block/blk-merge.c
>
> Yeah, may be re-working or extending MTD api with SG lists would be the
> way to go, but this is a lot more work...
Sorry, it would be correct to say that re-working MTD API _users_ to
incorporate the SG API would be a lot more work.
--
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/20121021/28e3b5cc/attachment.sig>
^ permalink raw reply
* [PATCH 6/7] crypto: omap-sham: Add code to use dmaengine API
From: Kasatkin, Dmitry @ 2012-10-21 11:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350683640-15044-7-git-send-email-mgreer@animalcreek.com>
Hello,
I got only 3 patches out of 7.
Can you please re-submit them also to linux-crypto at vger.kernel.org
That is a list where crypto drivers are discussed.
Thanks.
- Dmitry
On Sat, Oct 20, 2012 at 12:53 AM, Mark A. Greer <mgreer@animalcreek.com> wrote:
> From: "Mark A. Greer" <mgreer@animalcreek.com>
>
> Add code to use the new dmaengine API alongside
> the existing DMA code that uses the private
> OMAP DMA API. The API to use is chosen by
> defining or undefining 'OMAP_SHAM_DMA_PRIVATE'.
>
> CC: Russell King <rmk+kernel@arm.linux.org.uk>
> CC: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
> Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
> ---
> drivers/crypto/omap-sham.c | 150 +++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 145 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index acb85df..c782f60 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -13,6 +13,8 @@
> * Some ideas are from old omap-sha1-md5.c driver.
> */
>
> +#define OMAP_SHAM_DMA_PRIVATE
> +
> #define pr_fmt(fmt) "%s: " fmt, __func__
>
> #include <linux/err.h>
> @@ -27,6 +29,10 @@
> #include <linux/platform_device.h>
> #include <linux/scatterlist.h>
> #include <linux/dma-mapping.h>
> +#ifndef OMAP_SHAM_DMA_PRIVATE
> +#include <linux/dmaengine.h>
> +#include <linux/omap-dma.h>
> +#endif
> #include <linux/pm_runtime.h>
> #include <linux/delay.h>
> #include <linux/crypto.h>
> @@ -37,9 +43,11 @@
> #include <crypto/hash.h>
> #include <crypto/internal/hash.h>
>
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> #include <plat/cpu.h>
> #include <plat/dma.h>
> #include <mach/irqs.h>
> +#endif
>
> #define SHA_REG_DIGEST(x) (0x00 + ((x) * 0x04))
> #define SHA_REG_DIN(x) (0x1C + ((x) * 0x04))
> @@ -47,6 +55,8 @@
> #define SHA1_MD5_BLOCK_SIZE SHA1_BLOCK_SIZE
> #define MD5_DIGEST_SIZE 16
>
> +#define DST_MAXBURST 16 /* Really element number (en) */
> +
> #define SHA_REG_DIGCNT 0x14
>
> #define SHA_REG_CTRL 0x18
> @@ -110,6 +120,9 @@ struct omap_sham_reqctx {
>
> /* walk state */
> struct scatterlist *sg;
> +#ifndef OMAP_SHAM_DMA_PRIVATE
> + struct scatterlist sgl;
> +#endif
> unsigned int offset; /* offset in current sg */
> unsigned int total; /* total request */
>
> @@ -143,8 +156,12 @@ struct omap_sham_dev {
> int irq;
> spinlock_t lock;
> int err;
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> int dma;
> int dma_lch;
> +#else
> + struct dma_chan *dma_lch;
> +#endif
> struct tasklet_struct done_task;
>
> unsigned long flags;
> @@ -312,15 +329,32 @@ static int omap_sham_xmit_cpu(struct omap_sham_dev *dd, const u8 *buf,
> return -EINPROGRESS;
> }
>
> +#ifndef OMAP_SHAM_DMA_PRIVATE
> +static void omap_sham_dma_callback(void *param)
> +{
> + struct omap_sham_dev *dd = param;
> +
> + set_bit(FLAGS_DMA_READY, &dd->flags);
> + tasklet_schedule(&dd->done_task);
> +}
> +#endif
> +
> static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
> - size_t length, int final)
> + size_t length, int final, int is_sg)
> {
> struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> int len32;
> +#else
> + struct dma_async_tx_descriptor *tx;
> + struct dma_slave_config cfg;
> + int ret;
> +#endif
>
> dev_dbg(dd->dev, "xmit_dma: digcnt: %d, length: %d, final: %d\n",
> ctx->digcnt, length, final);
>
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> len32 = DIV_ROUND_UP(length, sizeof(u32));
>
> omap_set_dma_transfer_params(dd->dma_lch, OMAP_DMA_DATA_TYPE_S32, len32,
> @@ -330,6 +364,48 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
> omap_set_dma_src_params(dd->dma_lch, 0, OMAP_DMA_AMODE_POST_INC,
> dma_addr, 0, 0);
>
> +#else
> + memset(&cfg, 0, sizeof(cfg));
> +
> + cfg.dst_addr = dd->phys_base + SHA_REG_DIN(0);
> + cfg.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
> + cfg.dst_maxburst = DST_MAXBURST;
> +
> + ret = dmaengine_slave_config(dd->dma_lch, &cfg);
> + if (ret) {
> + pr_err("omap-sham: can't configure dmaengine slave: %d\n", ret);
> + return ret;
> + }
> +
> + if (is_sg) {
> + /*
> + * The SG entry passed in may not have the 'length' member
> + * set correctly so use a local SG entry (sgl) with the
> + * proper value for 'length' instead. If this is not done,
> + * the dmaengine may try to DMA the incorrect amount of data.
> + */
> + sg_init_table(&ctx->sgl, 1);
> + ctx->sgl.page_link = ctx->sg->page_link;
> + ctx->sgl.offset = ctx->sg->offset;
> + sg_dma_len(&ctx->sgl) = length;
> + sg_dma_address(&ctx->sgl) = sg_dma_address(ctx->sg);
> +
> + tx = dmaengine_prep_slave_sg(dd->dma_lch, &ctx->sgl, 1,
> + DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + } else {
> + tx = dmaengine_prep_slave_single(dd->dma_lch, dma_addr, length,
> + DMA_MEM_TO_DEV, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
> + }
> +
> + if (!tx) {
> + dev_err(dd->dev, "prep_slave_sg/single() failed\n");
> + return -EINVAL;
> + }
> +
> + tx->callback = omap_sham_dma_callback;
> + tx->callback_param = dd;
> +#endif
> +
> omap_sham_write_ctrl(dd, length, final, 1);
>
> ctx->digcnt += length;
> @@ -339,7 +415,12 @@ static int omap_sham_xmit_dma(struct omap_sham_dev *dd, dma_addr_t dma_addr,
>
> set_bit(FLAGS_DMA_ACTIVE, &dd->flags);
>
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> omap_start_dma(dd->dma_lch);
> +#else
> + dmaengine_submit(tx);
> + dma_async_issue_pending(dd->dma_lch);
> +#endif
>
> return -EINPROGRESS;
> }
> @@ -386,6 +467,8 @@ static int omap_sham_xmit_dma_map(struct omap_sham_dev *dd,
> struct omap_sham_reqctx *ctx,
> size_t length, int final)
> {
> + int ret;
> +
> ctx->dma_addr = dma_map_single(dd->dev, ctx->buffer, ctx->buflen,
> DMA_TO_DEVICE);
> if (dma_mapping_error(dd->dev, ctx->dma_addr)) {
> @@ -395,8 +478,12 @@ static int omap_sham_xmit_dma_map(struct omap_sham_dev *dd,
>
> ctx->flags &= ~BIT(FLAGS_SG);
>
> - /* next call does not fail... so no unmap in the case of error */
> - return omap_sham_xmit_dma(dd, ctx->dma_addr, length, final);
> + ret = omap_sham_xmit_dma(dd, ctx->dma_addr, length, final, 0);
> + if (ret)
> + dma_unmap_single(dd->dev, ctx->dma_addr, ctx->buflen,
> + DMA_TO_DEVICE);
> +
> + return ret;
> }
>
> static int omap_sham_update_dma_slow(struct omap_sham_dev *dd)
> @@ -431,6 +518,7 @@ static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
> struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
> unsigned int length, final, tail;
> struct scatterlist *sg;
> + int ret;
>
> if (!ctx->total)
> return 0;
> @@ -438,6 +526,17 @@ static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
> if (ctx->bufcnt || ctx->offset)
> return omap_sham_update_dma_slow(dd);
>
> +#ifndef OMAP_SHAM_DMA_PRIVATE
> + /*
> + * Don't use the sg interface when the transfer size is less
> + * than the number of elements in a DMA frame. Otherwise,
> + * the dmaengine infrastructure will calculate that it needs
> + * to transfer 0 frames which ultimately fails.
> + */
> + if (ctx->total < (DST_MAXBURST * sizeof(u32)))
> + return omap_sham_update_dma_slow(dd);
> +#endif
> +
> dev_dbg(dd->dev, "fast: digcnt: %d, bufcnt: %u, total: %u\n",
> ctx->digcnt, ctx->bufcnt, ctx->total);
>
> @@ -475,8 +574,11 @@ static int omap_sham_update_dma_start(struct omap_sham_dev *dd)
>
> final = (ctx->flags & BIT(FLAGS_FINUP)) && !ctx->total;
>
> - /* next call does not fail... so no unmap in the case of error */
> - return omap_sham_xmit_dma(dd, sg_dma_address(ctx->sg), length, final);
> + ret = omap_sham_xmit_dma(dd, sg_dma_address(ctx->sg), length, final, 1);
> + if (ret)
> + dma_unmap_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE);
> +
> + return ret;
> }
>
> static int omap_sham_update_cpu(struct omap_sham_dev *dd)
> @@ -495,7 +597,12 @@ static int omap_sham_update_dma_stop(struct omap_sham_dev *dd)
> {
> struct omap_sham_reqctx *ctx = ahash_request_ctx(dd->req);
>
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> omap_stop_dma(dd->dma_lch);
> +#else
> + dmaengine_terminate_all(dd->dma_lch);
> +#endif
> +
> if (ctx->flags & BIT(FLAGS_SG)) {
> dma_unmap_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE);
> if (ctx->sg->length == ctx->offset) {
> @@ -696,6 +803,7 @@ static int omap_sham_handle_queue(struct omap_sham_dev *dd,
> if (err)
> goto err1;
>
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> omap_set_dma_dest_params(dd->dma_lch, 0,
> OMAP_DMA_AMODE_CONSTANT,
> dd->phys_base + SHA_REG_DIN(0), 0, 16);
> @@ -705,6 +813,7 @@ static int omap_sham_handle_queue(struct omap_sham_dev *dd,
>
> omap_set_dma_src_burst_mode(dd->dma_lch,
> OMAP_DMA_DATA_BURST_4);
> +#endif
>
> if (ctx->digcnt)
> /* request has changed - restore hash */
> @@ -1096,6 +1205,7 @@ static irqreturn_t omap_sham_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> static void omap_sham_dma_callback(int lch, u16 ch_status, void *data)
> {
> struct omap_sham_dev *dd = data;
> @@ -1133,12 +1243,17 @@ static void omap_sham_dma_cleanup(struct omap_sham_dev *dd)
> dd->dma_lch = -1;
> }
> }
> +#endif
>
> static int __devinit omap_sham_probe(struct platform_device *pdev)
> {
> struct omap_sham_dev *dd;
> struct device *dev = &pdev->dev;
> struct resource *res;
> +#ifndef OMAP_SHAM_DMA_PRIVATE
> + dma_cap_mask_t mask;
> + unsigned dma_chan;
> +#endif
> int err, i, j;
>
> dd = kzalloc(sizeof(struct omap_sham_dev), GFP_KERNEL);
> @@ -1173,7 +1288,11 @@ static int __devinit omap_sham_probe(struct platform_device *pdev)
> err = -ENODEV;
> goto res_err;
> }
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> dd->dma = res->start;
> +#else
> + dma_chan = res->start;
> +#endif
>
> /* Get the IRQ */
> dd->irq = platform_get_irq(pdev, 0);
> @@ -1190,9 +1309,22 @@ static int __devinit omap_sham_probe(struct platform_device *pdev)
> goto res_err;
> }
>
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> err = omap_sham_dma_init(dd);
> if (err)
> goto dma_err;
> +#else
> + dma_cap_zero(mask);
> + dma_cap_set(DMA_SLAVE, mask);
> +
> + dd->dma_lch = dma_request_channel(mask, omap_dma_filter_fn, &dma_chan);
> + if (!dd->dma_lch) {
> + dev_err(dev, "unable to obtain RX DMA engine channel %u\n",
> + dma_chan);
> + err = -ENXIO;
> + goto dma_err;
> + }
> +#endif
>
> dd->io_base = ioremap(dd->phys_base, SZ_4K);
> if (!dd->io_base) {
> @@ -1226,7 +1358,11 @@ err_algs:
> iounmap(dd->io_base);
> pm_runtime_disable(dev);
> io_err:
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> omap_sham_dma_cleanup(dd);
> +#else
> + dma_release_channel(dd->dma_lch);
> +#endif
> dma_err:
> if (dd->irq >= 0)
> free_irq(dd->irq, dd);
> @@ -1256,7 +1392,11 @@ static int __devexit omap_sham_remove(struct platform_device *pdev)
> iounmap(dd->io_base);
> pm_runtime_put_sync(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
> +#ifdef OMAP_SHAM_DMA_PRIVATE
> omap_sham_dma_cleanup(dd);
> +#else
> + dma_release_channel(dd->dma_lch);
> +#endif
> if (dd->irq >= 0)
> free_irq(dd->irq, dd);
> kfree(dd);
> --
> 1.7.12
>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Richard Cochran @ 2012-10-21 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210210804060.10693@utopia.booyaka.com>
On Sun, Oct 21, 2012 at 08:23:35AM +0000, Paul Walmsley wrote:
> On Sun, 21 Oct 2012, Richard Cochran wrote:
>
> > When I read your report, it gave me a much rosier picture than is
> > actually the case WRT the beaglebone.
>
> Really? What section of the message provided that to you?
It was the part that said,
Passing tests
-------------
Boot to userspace: 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm,
4430es2panda, 5912osk, am335xbone
It sounded to me like you were saying that the current kernel release
boots just fine on the beaglebone, with no issues.
It surprised me, because in fact I have had one heck of a time getting
the beaglebone to boot. It is a bit of a cop-out to say that you are
not interested in the boot loader. Way back when the whole "dt is so
cool, arm should use it too" argument appeared, I wrote that, in my
experience with Freescale powerpc chips, the whole kernel/dt/u-boot is
a kind of Bermuda Triangle of misfortune. Looks like that dt is
turning out to be just as successful for arm as it was for powerpc.
Thanks,
Richard
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Artem Bityutskiy @ 2012-10-21 11:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAN8TOE91TDewmo=w7585sDrsXcPmBnvOjmD7sTizPSJ8RH8_Gg@mail.gmail.com>
On Sun, 2012-10-21 at 00:38 -0700, Brian Norris wrote:
> >> This is good idea, the problem is that it is a bit more work than
> >> hacking the driver, so most people prefer the latter. By removing all
> >> kmalloc()'s I basically wish to force people to go this way.
>
> Did you mean vmalloc()'s?
Yes.
>
> >> What are the SC functions names you refer?
> >
> > I'm mainly thinking of blk_rq_map_sg()
> > from block/blk-merge.c
Yeah, may be re-working or extending MTD api with SG lists would be the
way to go, but this is a lot more work...
--
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/20121021/243509aa/attachment.sig>
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Paul Walmsley @ 2012-10-21 8:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121021073551.GA4735@netboy.at.omicron.at>
On Sun, 21 Oct 2012, Richard Cochran wrote:
> You are using an obsolete u-boot and the "legacy" appended dtb
> method. It was my understanding that that way is just a temporary hack
> in case the boot loader does not support dtb.
>
> Now that u-boot has the proper support, using the dtb method is the
> "offical" boot method, AFAICT. At least, that is what people are
> saying on the arm list. So I think that if you want to test whether a
> particular board is booting correctly, it is more useful to try the
> offical method.
I'm not interested in testing the bootloader, only the kernel.
And in particular, my focus is currently on the OMAP-specific parts of the
boot and the PM code, not any kernel DT code.
> People keep saying, the beaglebone works fine with v3.7-rc1, but it
> isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been
> fixed, and no one is doing anything about it either.
There's likely to be quite a bit that doesn't work in the AM335x boards in
mainline, due to the fact that it's the first OMAP DT-only board. Many
device drivers and subsystems are still not fully adapted to DT across
most ARM boards.
> When I read your report, it gave me a much rosier picture than is
> actually the case WRT the beaglebone.
Really? What section of the message provided that to you?
- Paul
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Brian Norris @ 2012-10-21 7:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdY2=PLS_MT1h_nQJj+2ju26yXtt-aXSi=t9uUQ5+WJasA@mail.gmail.com>
On Tue, Oct 16, 2012 at 3:05 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Tue, Oct 16, 2012 at 9:14 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
>> On Mon, 2012-10-15 at 21:51 +0200, Linus Walleij wrote:
>>> On Mon, Oct 15, 2012 at 6:27 PM, Brian Norris
>>> <computersforpeace@gmail.com> wrote:
>>>
>>> > I would prefer not building a solution that hopes kmalloc() can get a
>>> > large contiguous buffer (remember, eraseblock sizes come as large as
>>> > 2MB these days). A real solution like CMA or scatter-gather seems like
>>> > a better idea.
>>>
>>> +1 on that, and as I think I illustrated the MMC subsystem is using
>>> the block layer helpers to form scatter-gather lists for it's requests.
>>> I don't see why the MTD subsystem need to be very different?
>>
>> This is good idea, the problem is that it is a bit more work than
>> hacking the driver, so most people prefer the latter. By removing all
>> kmalloc()'s I basically wish to force people to go this way.
Did you mean vmalloc()'s?
>> What are the SC functions names you refer?
>
> I'm mainly thinking of blk_rq_map_sg()
> from block/blk-merge.c
I am also interested in the potential for the S-G approach. I'll see
what kind of work it takes to implement soon, hopefully.
As a side note, my hardware can, in fact, perform scatter-gather DMA.
If we were to support both S-G hardware like mine in addition to
standard, page-at-time access (nand_chip->write_page, for example),
could we introduce a DMA interface to nand_chip? Then this interface
would just be set to NULL for those that can't handle it.
Brian
^ permalink raw reply
* OMAP baseline test results for v3.7-rc1
From: Richard Cochran @ 2012-10-21 7:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1210201615170.24497@utopia.booyaka.com>
On Sat, Oct 20, 2012 at 04:27:19PM +0000, Paul Walmsley wrote:
> Here's the console log from the boot test here:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/boot/am335xbone/am335xbone_log.txt
>
> And here's the kernel config and uImage+DTB from the boot test here:
>
> http://www.pwsan.com/omap/testlogs/test_v3.7-rc1/20121017205513/build/am33xx_only/
>
> In terms of differences from your setup, looks like we have different
> X-Loader and u-boot; it wouldn't surprise me if we have different kernel
> configs too.
Paul,
You are using an obsolete u-boot and the "legacy" appended dtb
method. It was my understanding that that way is just a temporary hack
in case the boot loader does not support dtb.
Now that u-boot has the proper support, using the dtb method is the
"offical" boot method, AFAICT. At least, that is what people are
saying on the arm list. So I think that if you want to test whether a
particular board is booting correctly, it is more useful to try the
offical method.
People keep saying, the beaglebone works fine with v3.7-rc1, but it
isn't true. Now v3.7-rc2 is out, and the gpmc issue still has not been
fixed, and no one is doing anything about it either.
When I read your report, it gave me a much rosier picture than is
actually the case WRT the beaglebone.
Thanks,
Richard
^ permalink raw reply
* [PATCH 07/11] fsmc/nand: Provide contiguous buffers to dma
From: Brian Norris @ 2012-10-21 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350371511.5769.43.camel@sauron.fi.intel.com>
On Tue, Oct 16, 2012 at 12:11 AM, Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Mon, 2012-10-15 at 09:27 -0700, Brian Norris wrote:
>> See the commit description for the following commit in mtd-utils.git:
>>
>> commit 71c76e74661492b4f68f670514866cfc85f47089
>> libmtd: fix mtd_write() issues for large data-only writes
>
> Well, this is another work-around.
Yeah, I know it was a workaround. It's another issue of balancing time
and the "best" solution. Of course, the solutions actually don't seem
that difficult now, so I probably should have just fixed the ioctl()
in the first place... But I was simply pointing this out as evidence
of a real memory-fragmentation issue.
> The better way to fix this would be
> to change kernel's 'mtdchar_write_ioctl()' to be iterative and avoid
> calling 'memdup_user(len)' for arbitrary 'len' passed from user-space.
That's one way, but it would require specifying some arbitrary
iteration length, right? Like some multiple of writesize?
Instead, how about modelling it more closely after mtdchar_write(),
using mtd_kmalloc_up_to(), then iteratively call copy_from_user()?
> So I thought about something like introducing an mtd_alloc() which
> would:
> a. Try doing CMA allocation: dma_alloc_from_contiguous()
> b. If it fails, use kmalloc().
...
> If both fail - bad luck. Go look at the code and switch to S-G lists
> instead of allocating contiguous regions. As I said, in many places it
> is easy to do, and there are few places when you would need to spend a
> bit more time.
>
> How does this sound to you?
It sounds OK, but that depends on the success rate of
dma_alloc_from_contiguous(). I'm not familiar with it.
Brian
^ permalink raw reply
* [PATCH] usb: phy: samsung: Introducing usb phy driver for hsotg
From: Domenico Andreoli @ 2012-10-21 7:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121017191300.GL21164@n2100.arm.linux.org.uk>
On Wed, Oct 17, 2012 at 08:13:01PM +0100, Russell King - ARM Linux wrote:
> On Wed, Oct 17, 2012 at 08:00:00PM +0900, Kukjin Kim wrote:
> > > +static int samsung_usbphy_get_refclk_freq(struct samsung_usbphy *sphy)
> > > +{
> > > + struct clk *ref_clk;
> > > + int refclk_freq = 0;
> > > +
> > > + ref_clk = clk_get(sphy->dev, "xusbxti");
> > > + if (IS_ERR(ref_clk)) {
> >
> > IS_ERR_OR_NULL(ref_clk)?
>
> For the N'th time, NO. IS_ERR is correct here.
>
> > > + dev_err(sphy->dev, "Failed to get reference clock\n");
> > > + return PTR_ERR(ref_clk);
>
> Look, it's the ABI. Not only that but it's also TOTALLY AND UTTERLY WRONG
> to use IS_ERR_OR_NULL(foo) and then follow it with return PTR_ERR(foo).
> You end up returning ZERO.
>
> Stop telling people to use IS_ERR_OR_NULL without properly thinking about
> it first. Virtually every single one of these done this way is a BUG.
>
> Are we clear on this?
Wouldn't be much easier to define PTR_ERR() to return -Esomething when
its argument is NULL?
This would end the whole issue of "should I use IS_ERR*/PTR_ERR or look into
the pointer myself?" story. One could simply always use IS_ERR*/PTR_ERR
and have the right thing done in whatever case.
Regards,
Domenico
^ permalink raw reply
* [PATCH 2/2] ARM: kirkwood: use gpio-fan DT binding on lsxl
From: Andrew Lunn @ 2012-10-21 6:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350776094-16778-2-git-send-email-michael@walle.cc>
On Sun, Oct 21, 2012 at 01:34:54AM +0200, Michael Walle wrote:
> Remove board specific gpio-fan driver registration. Moved into device tree.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> arch/arm/boot/dts/kirkwood-lsxl.dtsi | 11 ++++++++
> arch/arm/mach-kirkwood/board-lsxl.c | 47 ----------------------------------
> 2 files changed, 11 insertions(+), 47 deletions(-)
>
> diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> index 8fea375..798e60e 100644
> --- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> @@ -94,4 +94,15 @@
> gpios = <&gpio1 16 1>;
> };
> };
> +
> + gpio_fan {
> + compatible = "gpio-fan";
> + gpios = <&gpio0 19 1
> + &gpio0 18 1>;
> + gpio-fan,speed-map = <0 3
> + 1500 2
> + 3250 1
> + 5000 0>;
> + alarm-gpios = <&gpio1 8 0>;
> + };
> };
> diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
> index 64e5cc6..7e18cad 100644
> --- a/arch/arm/mach-kirkwood/board-lsxl.c
> +++ b/arch/arm/mach-kirkwood/board-lsxl.c
> @@ -16,7 +16,6 @@
> #include <linux/platform_device.h>
> #include <linux/mv643xx_eth.h>
> #include <linux/gpio.h>
> -#include <linux/gpio-fan.h>
> #include "common.h"
> #include "mpp.h"
Hi Michael
You might also be able to remove platform_device.h.
Otherwise, it looks good.
Andrew
^ permalink raw reply
* [PATCH V2] ARM: Kirkwood: new board USI Topkick
From: Andrew Lunn @ 2012-10-21 6:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350763764-737-1-git-send-email-jason@lakedaemon.net>
On Sat, Oct 20, 2012 at 08:09:24PM +0000, Jason Cooper wrote:
> This is a new kirkwood box made by Universal Scientific Industrial, Inc.
> The product description is here:
>
> http://www.usish.com/english/products_topkick1281p2.php
>
> It is very similar to the dreamplug and other plug devices, with the
> exception that it has room for a 2.5" SATA HDD internally.
>
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> ---
> Changes since V1:
> - changes nr-ports to 1 for sata0
> - included board in defconfig
> - trimmed #includes
> - added mvsdio init call
>
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/kirkwood-topkick.dts | 85 ++++++++++++++++++++++++++++++
> arch/arm/configs/kirkwood_defconfig | 1 +
> arch/arm/mach-kirkwood/Kconfig | 7 +++
> arch/arm/mach-kirkwood/Makefile | 1 +
> arch/arm/mach-kirkwood/board-dt.c | 4 ++
> arch/arm/mach-kirkwood/board-usi_topkick.c | 83 +++++++++++++++++++++++++++++
> arch/arm/mach-kirkwood/common.h | 6 +++
> 8 files changed, 189 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/boot/dts/kirkwood-topkick.dts
> create mode 100644 arch/arm/mach-kirkwood/board-usi_topkick.c
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c1ce813..04fffc7 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -38,7 +38,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-dns320.dtb \
> kirkwood-lschlv2.dtb \
> kirkwood-lsxhl.dtb \
> kirkwood-ts219-6281.dtb \
> - kirkwood-ts219-6282.dtb
> + kirkwood-ts219-6282.dtb \
> + kirkwood-topkick.dtb
Hi Jason
These are sorted in alphabetic order. So topkick should be before
ts219. Keeping them sorted reduced merge conflicts.
> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> msm8960-cdp.dtb
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> diff --git a/arch/arm/boot/dts/kirkwood-topkick.dts b/arch/arm/boot/dts/kirkwood-topkick.dts
> new file mode 100644
> index 0000000..c0de5a7
> --- /dev/null
> +++ b/arch/arm/boot/dts/kirkwood-topkick.dts
> @@ -0,0 +1,85 @@
> +/dts-v1/;
> +
> +/include/ "kirkwood.dtsi"
> +
> +/ {
> + model = "Univeral Scientific Industrial Co. Topkick-1281P2";
> + compatible = "usi,topkick-1281P2", "usi,topkick", "marvell,kirkwood-88f6282", "marvell,kirkwood";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x10000000>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
> + };
> +
> + ocp at f1000000 {
> + serial at 12000 {
> + clock-frequency = <200000000>;
> + status = "ok";
> + };
> +
> + nand at 3000000 {
> + status = "okay";
> +
> + partition at 0 {
> + label = "u-boot";
> + reg = <0x0000000 0x180000>;
> + };
> +
> + partition at 180000 {
> + label = "u-boot env";
> + reg = <0x0180000 0x20000>;
> + };
> +
> + partition at 200000 {
> + label = "uImage";
> + reg = <0x0200000 0x600000>;
> + };
> +
> + partition at 800000 {
> + label = "uInitrd";
> + reg = <0x0800000 0x1000000>;
> + };
> +
> + partition at 1800000 {
> + label = "rootfs";
> + reg = <0x1800000 0xe800000>;
> + };
> + };
> +
> + sata at 80000 {
> + status = "okay";
> + nr-ports = <1>;
> + };
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + disk {
> + label = "topkick:yellow:disk";
> + gpios = <&gpio0 21 1>;
> + linux,default-trigger = "ide-disk";
> + };
> + system2 {
> + label = "topkick:red:system";
> + gpios = <&gpio1 5 1>;
> + };
> + system {
> + label = "topkick:blue:system";
> + gpios = <&gpio1 6 1>;
> + default-state = "on";
> + };
> + wifi {
> + label = "topkick:green:wifi";
> + gpios = <&gpio1 7 1>;
> + };
> + wifi2 {
> + label = "topkick:yellow:wifi";
> + gpios = <&gpio1 16 1>;
> + };
> + };
> +};
> diff --git a/arch/arm/configs/kirkwood_defconfig b/arch/arm/configs/kirkwood_defconfig
> index 74eee0c..72d6c28 100644
> --- a/arch/arm/configs/kirkwood_defconfig
> +++ b/arch/arm/configs/kirkwood_defconfig
> @@ -27,6 +27,7 @@ CONFIG_MACH_GOFLEXNET_DT=y
> CONFIG_MACH_LSXL_DT=y
> CONFIG_MACH_IOMEGA_IX2_200_DT=y
> CONFIG_MACH_KM_KIRKWOOD_DT=y
> +CONFIG_MACH_TOPKICK_DT=y
> CONFIG_MACH_TS219=y
> CONFIG_MACH_TS41X=y
> CONFIG_MACH_DOCKSTAR=y
> diff --git a/arch/arm/mach-kirkwood/Kconfig b/arch/arm/mach-kirkwood/Kconfig
> index 50bca50..b8b5c22 100644
> --- a/arch/arm/mach-kirkwood/Kconfig
> +++ b/arch/arm/mach-kirkwood/Kconfig
> @@ -130,6 +130,13 @@ config MACH_KM_KIRKWOOD_DT
> Say 'Y' here if you want your kernel to support the
> Keymile Kirkwood Reference Desgin, using Flattened Device Tree.
>
> +config MACH_TOPKICK_DT
> + bool "USI Topkick (Flattened Device Tree)"
> + select ARCH_KIRKWOOD_DT
> + help
> + Say 'Y' here if you want your kernel to support the
> + USI Topkick, using Flattened Device Tree
> +
> config MACH_TS219
> bool "QNAP TS-110, TS-119, TS-119P+, TS-210, TS-219, TS-219P and TS-219P+ Turbo NAS"
> help
> diff --git a/arch/arm/mach-kirkwood/Makefile b/arch/arm/mach-kirkwood/Makefile
> index 294779f..bd463df 100644
> --- a/arch/arm/mach-kirkwood/Makefile
> +++ b/arch/arm/mach-kirkwood/Makefile
> @@ -31,3 +31,4 @@ obj-$(CONFIG_MACH_GOFLEXNET_DT) += board-goflexnet.o
> obj-$(CONFIG_MACH_LSXL_DT) += board-lsxl.o
> obj-$(CONFIG_MACH_IOMEGA_IX2_200_DT) += board-iomega_ix2_200.o
> obj-$(CONFIG_MACH_KM_KIRKWOOD_DT) += board-km_kirkwood.o
> +obj-$(CONFIG_MACH_TOPKICK_DT) += board-usi_topkick.o
> diff --git a/arch/arm/mach-kirkwood/board-dt.c b/arch/arm/mach-kirkwood/board-dt.c
> index 70c5a28..33e9217 100644
> --- a/arch/arm/mach-kirkwood/board-dt.c
> +++ b/arch/arm/mach-kirkwood/board-dt.c
> @@ -96,6 +96,9 @@ static void __init kirkwood_dt_init(void)
> if (of_machine_is_compatible("keymile,km_kirkwood"))
> km_kirkwood_init();
>
> + if (of_machine_is_compatible("usi,topkick"))
> + usi_topkick_init();
> +
> of_platform_populate(NULL, kirkwood_dt_match_table,
> kirkwood_auxdata_lookup, NULL);
> }
> @@ -112,6 +115,7 @@ static const char *kirkwood_dt_board_compat[] = {
> "buffalo,lsxl",
> "iom,ix2-200",
> "keymile,km_kirkwood",
> + "usi,topkick",
> NULL
> };
>
> diff --git a/arch/arm/mach-kirkwood/board-usi_topkick.c b/arch/arm/mach-kirkwood/board-usi_topkick.c
> new file mode 100644
> index 0000000..a5e0826
> --- /dev/null
> +++ b/arch/arm/mach-kirkwood/board-usi_topkick.c
> @@ -0,0 +1,83 @@
> +/*
> + * Copyright 2012 (C), Jason Cooper <jason@lakedaemon.net>
> + *
> + * arch/arm/mach-kirkwood/board-dreamplug.c
board-usi_topkick.c
> + *
> + * Marvell DreamPlug Reference Board Init for drivers not converted to
> + * flattened device tree yet.
Comment needs updating...
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/mv643xx_eth.h>
> +#include <linux/gpio.h>
> +#include <linux/platform_data/mmc-mvsdio.h>
> +#include "common.h"
> +#include "mpp.h"
> +
> +static struct mv643xx_eth_platform_data topkick_ge00_data = {
> + .phy_addr = MV643XX_ETH_PHY_ADDR(0),
> +};
> +
> +static struct mvsdio_platform_data topkick_mvsdio_data = {
> + /* unfortunately the CD signal has not been connected */
> +};
Is this just cut/paste, or has it been verified that CD is not
connected?
Andrew
^ permalink raw reply
* [PATCH 2/5 v6] gpio: Add sysfs support to block GPIO API
From: Greg KH @ 2012-10-21 4:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350728508-22508-3-git-send-email-stigge@antcom.de>
On Sat, Oct 20, 2012 at 12:21:45PM +0200, Roland Stigge wrote:
> This patch adds sysfs support to the block GPIO API.
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
Thanks for the updates, looks good to me:
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH v2 1/2] USB: Update EHCI-platform driver to devicetree.
From: Alan Stern @ 2012-10-21 2:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350771032-11527-2-git-send-email-linux@prisktech.co.nz>
On Sun, 21 Oct 2012, Tony Prisk wrote:
> This patch adds devicetree support to the EHCI-platform driver,
> and removes the now unneeded ehci-vt8500.c
>
> Existing platform properties are maintained, with the exception
> the power_(on/off) and suspend function pointers.
Unfortunately this can't be accepted as is, because Florian's patches
are ahead of yours in the queue. You'll have to respin this after his
stuff has been merged.
> --- a/drivers/usb/host/ehci-platform.c
> +++ b/drivers/usb/host/ehci-platform.c
> @@ -19,6 +19,7 @@
> * Licensed under the GNU/GPL. See COPYING for details.
> */
> #include <linux/platform_device.h>
> +#include <linux/of.h>
> #include <linux/usb/ehci_pdriver.h>
>
> static int ehci_platform_reset(struct usb_hcd *hcd)
> @@ -78,14 +79,60 @@ static const struct hc_driver ehci_platform_hc_driver = {
> .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
> };
>
> +static u64 ehci_dma_mask = DMA_BIT_MASK(32);
Just out of curiosity... Instead of adding this same code (which will
all have to be removed later) to millions of drivers, why doesn't
somebody add support for DMA masks into DT?
> + * No platform data is being passed, so initalize pdata.
> + * Limitation: we can't support power_on, power_off or
> + * power_suspend function pointers from DT.
> + * TODO: The missing functions could be replaced with
> + * power sequence handlers.
> + */
> + pdata = devm_kzalloc(&dev->dev, sizeof(*pdata), GFP_KERNEL);
> + dev->dev.platform_data = pdata;
> +
> + if (!pdata) {
> + pr_err("device tree platform data allocation failed\n");
Don't use pr_err; use dev_err.
> @@ -101,7 +148,7 @@ static int __devinit ehci_platform_probe(struct platform_device *dev)
> }
> res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
> if (!res_mem) {
> - pr_err("no memory recourse provided");
> + pr_err("no memory resource provided");
This has already been fixed in Florian's patches.
>
> @@ -163,6 +210,7 @@ static int __devexit ehci_platform_remove(struct platform_device *dev)
> release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
> usb_put_hcd(hcd);
> platform_set_drvdata(dev, NULL);
> + devm_kfree(&dev->dev, pdata);
This isn't needed. That's the whole point of the devm_* family of
routines; the resources they allocate are automatically released when
the device is removed.
> --- a/include/linux/usb/ehci_pdriver.h
> +++ b/include/linux/usb/ehci_pdriver.h
> @@ -41,6 +41,7 @@ struct usb_ehci_pdata {
> unsigned big_endian_mmio:1;
> unsigned port_power_on:1;
> unsigned port_power_off:1;
> + unsigned no_io_watchdog:1;
This is also in Florian's patches.
Alan Stern
^ permalink raw reply
* [PATCH v3 0/7] mv643xx.c: Add basic device tree support.
From: Jason Cooper @ 2012-10-21 1:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1347343411.2603.42.camel@pasglop>
Pong. ;-)
On Tue, Sep 11, 2012 at 04:03:31PM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2012-09-10 at 14:22 +0000, Arnd Bergmann wrote:
> > Following up on the old discussion, I talked briefly about this
> > issue with BenH at the kernel summit. The outcome basically is that
> > it's a bit sad to have incompatible bindings, but it's not the end
> > of the world,and it's more important to do it right this time.
> >
> > Just make sure that you use different values for the 'compatible'
> > strings and then do what you need to get the ARM hardware working.
> >
> > Ideally, the new binding should be written in a way that powerpc
> > machines can use the same one, but the existing ones all use
> > an version of Open Firmware that is not going to get updated
> > and it's also not too likely that we are going to see new
> > powerpc machines based on this chip.
>
> Right, mostly these machines where the Pegasos. Those came with a fairly
> busted variant of Open Firmware which generated a pretty gross
> device-tree.
>
> For some reason, the manufacturer of those things was never willing to
> fix anything in their firmware (despite the distributor providing
> patches etc...), seemingly on the assumption that whatever they were
> doing was perfect and operating system people like us didn't matter one
> little bit :-)
>
> So I don't care much about it. It would be nice to keep them working
> since people in the community still have them but if it goes through
> some "compat" code that detects old/broken device-trees and eventually
> disappears when we finally drop support, then so be it.
Ian,
What is the status of this work?
thx,
Jason.
^ permalink raw reply
* [PATCH v2 0/2] DT EHCI support for Kirkwood.
From: Jason Cooper @ 2012-10-21 1:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350731401-21442-1-git-send-email-andrew@lunn.ch>
On Sat, Oct 20, 2012 at 01:09:59PM +0200, Andrew Lunn wrote:
> These two patches add DT support to ehci-orion and convert all
> existing Kirkwood DT boards to using DT to instantiate the USB host.
>
> v1->v2: Remove the phy property from DT. The previous implementation
> was not compatible with the new ideas of a USB phy node. Only orion5x
> needs it anyway, and currently converting orion5x to DT is low
> priority. Adding a phy node later will also not affect backwards
> compatibility.
>
> Andrew Lunn (2):
> ARM: Kirkwood: ehci-orion: Add device tree binding
> ARM: Kirkwood: Convert all DT boards to EHCI via DT.
>
> .../devicetree/bindings/usb/ehci-orion.txt | 15 ++++++++
> arch/arm/boot/dts/kirkwood.dtsi | 7 ++++
> arch/arm/mach-kirkwood/board-dnskw.c | 1 -
> arch/arm/mach-kirkwood/board-dockstar.c | 1 -
> arch/arm/mach-kirkwood/board-dreamplug.c | 1 -
> arch/arm/mach-kirkwood/board-dt.c | 1 +
> arch/arm/mach-kirkwood/board-goflexnet.c | 1 -
> arch/arm/mach-kirkwood/board-ib62x0.c | 1 -
> arch/arm/mach-kirkwood/board-iconnect.c | 1 -
> arch/arm/mach-kirkwood/board-iomega_ix2_200.c | 2 --
> arch/arm/mach-kirkwood/board-km_kirkwood.c | 1 -
> arch/arm/mach-kirkwood/board-lsxl.c | 1 -
> arch/arm/mach-kirkwood/board-ts219.c | 1 -
> drivers/usb/host/ehci-orion.c | 38 ++++++++++++++++++--
> 14 files changed, 58 insertions(+), 14 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/usb/ehci-orion.txt
Applied to:
git://git.infradead.org/users/jcooper/linux.git kirkwood/dt
thx,
Jason.
^ permalink raw reply
* [PATCH] [ARM] Enable the second I2C bus on Marvell Kirkwood
From: Jason Cooper @ 2012-10-21 1:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121001235932.GA678@obsidianresearch.com>
On Mon, Oct 01, 2012 at 05:59:32PM -0600, Jason Gunthorpe wrote:
> mv64xxx_of_config requires that the tclk frequency be found
> through the clk stuff rather than through device tree, so add
> another override for the 2nd controller.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
I made one small change, changed subject to:
ARM: Kirkwood: Enable the second I2C bus
Applied to:
git://git.infradead.org/users/jcooper/linux.git kirkwood/boards
thx,
Jason.
^ permalink raw reply
* [PATCH v2 0/4] Add DT support for Network Space v2 and parents
From: Jason Cooper @ 2012-10-21 1:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350468546-25901-1-git-send-email-simon.guinot@sequanux.org>
On Wed, Oct 17, 2012 at 12:09:02PM +0200, Simon Guinot wrote:
> This patch series provides DT support for LaCie NAS Network Space v2 and
> parents. This includes the following machines:
> - Internet Space v2
> - Network Space v2
> - Network Space Max v2
> - Network Space Lite v2
> - Network Space Mini v2
>
> Note that the three first boards are already supported by the Linux
> kernel via an "old-fashion" board setup. The two lasts (Lite and Mini)
> are new boards.
>
> Also note that the first patch of the series is related with the LED
> subsystem. It adds device tree binding to the driver leds-ns2.
Series applied to:
git://git.infradead.org/users/jcooper/linux.git kirkwood/boards
thx,
Jason.
^ permalink raw reply
* [GIT PULL][for 3.8] pull request of serial branch from arch pxa git tree
From: Haojian Zhuang @ 2012-10-21 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121020153932.GA6476@kroah.com>
OK. So let me send the patch to you.
Olof & Arnd,
Please ignore this request.
Best Regards
Haojian
On Sat, Oct 20, 2012 at 11:39 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Sat, Oct 20, 2012 at 11:27:34PM +0800, Haojian Zhuang wrote:
>> Hi Olof & Arnd,
>>
>> Please help to merge upload/serial branch in arch pxa git tree.
>
> Why not just send me the patch through email so I can take it that way?
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Which kirkwood does your DT board use?
From: Josh Coombs @ 2012-10-21 0:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121020113800.GC21046@lunn.ch>
On Sat, Oct 20, 2012 at 7:38 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> Hi Folks
>
> All of you in the To: have contributed a DT based Kirkwood board port.
> Nearly all the DT files we have declare the CPU to be
> marvell,kirkwood-88f6281. For adding DT based pinctrl, to replace the
> mpp code, we need to know the exact kirkwood being used. It should be
> one of MV88F6180, MV88F6190, MV88F6192, MV88F6281 or MV88F6282.
>
> You can see what your hardware has a boot time:
>
> Kirkwood: MV88F6282-Rev-A0, TCLK=200000000.
>
> Please could you check your hardware and let me know what the correct
> CPU is. I can then fix the .dts files and prepare a first attempt at
> converting boards to pinctrl.
>
> Thanks
> Andrew
Seagate GoFlexNet
[jcoombs at alarm ~]$ dmesg | grep -i tclk
[ 5.851008] Kirkwood: MV88F6281-A0, TCLK=200000000.
Joshua Coombs
^ permalink raw reply
* [PATCH 2/2] ARM: kirkwood: use gpio-fan DT binding on lsxl
From: Michael Walle @ 2012-10-20 23:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350776094-16778-1-git-send-email-michael@walle.cc>
Remove board specific gpio-fan driver registration. Moved into device tree.
Signed-off-by: Michael Walle <michael@walle.cc>
---
arch/arm/boot/dts/kirkwood-lsxl.dtsi | 11 ++++++++
arch/arm/mach-kirkwood/board-lsxl.c | 47 ----------------------------------
2 files changed, 11 insertions(+), 47 deletions(-)
diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
index 8fea375..798e60e 100644
--- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
+++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
@@ -94,4 +94,15 @@
gpios = <&gpio1 16 1>;
};
};
+
+ gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio0 19 1
+ &gpio0 18 1>;
+ gpio-fan,speed-map = <0 3
+ 1500 2
+ 3250 1
+ 5000 0>;
+ alarm-gpios = <&gpio1 8 0>;
+ };
};
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
index 64e5cc6..7e18cad 100644
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ b/arch/arm/mach-kirkwood/board-lsxl.c
@@ -16,7 +16,6 @@
#include <linux/platform_device.h>
#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
-#include <linux/gpio-fan.h>
#include "common.h"
#include "mpp.h"
@@ -45,51 +44,6 @@ static unsigned int lsxl_mpp_config[] __initdata = {
0
};
-#define LSXL_GPIO_FAN_HIGH 18
-#define LSXL_GPIO_FAN_LOW 19
-#define LSXL_GPIO_FAN_LOCK 40
-
-static struct gpio_fan_alarm lsxl_alarm = {
- .gpio = LSXL_GPIO_FAN_LOCK,
-};
-
-static struct gpio_fan_speed lsxl_speeds[] = {
- {
- .rpm = 0,
- .ctrl_val = 3,
- }, {
- .rpm = 1500,
- .ctrl_val = 1,
- }, {
- .rpm = 3250,
- .ctrl_val = 2,
- }, {
- .rpm = 5000,
- .ctrl_val = 0,
- }
-};
-
-static int lsxl_gpio_list[] = {
- LSXL_GPIO_FAN_HIGH, LSXL_GPIO_FAN_LOW,
-};
-
-static struct gpio_fan_platform_data lsxl_fan_data = {
- .num_ctrl = ARRAY_SIZE(lsxl_gpio_list),
- .ctrl = lsxl_gpio_list,
- .alarm = &lsxl_alarm,
- .num_speed = ARRAY_SIZE(lsxl_speeds),
- .speed = lsxl_speeds,
-};
-
-static struct platform_device lsxl_fan_device = {
- .name = "gpio-fan",
- .id = -1,
- .num_resources = 0,
- .dev = {
- .platform_data = &lsxl_fan_data,
- },
-};
-
/*
* On the LS-XHL/LS-CHLv2, the shutdown process is following:
* - Userland monitors key events until the power switch goes to off position
@@ -120,7 +74,6 @@ void __init lsxl_init(void)
kirkwood_ehci_init();
kirkwood_ge00_init(&lsxl_ge00_data);
kirkwood_ge01_init(&lsxl_ge01_data);
- platform_device_register(&lsxl_fan_device);
/* register power-off method */
pm_power_off = lsxl_power_off;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/2] ARM: kirkwood: cleanup lsxl board includes
From: Michael Walle @ 2012-10-20 23:34 UTC (permalink / raw)
To: linux-arm-kernel
Remove unneeded includes. These are leftovers from platform device
registrations.
Signed-off-by: Michael Walle <michael@walle.cc>
---
arch/arm/mach-kirkwood/board-lsxl.c | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-kirkwood/board-lsxl.c b/arch/arm/mach-kirkwood/board-lsxl.c
index 83d8975..64e5cc6 100644
--- a/arch/arm/mach-kirkwood/board-lsxl.c
+++ b/arch/arm/mach-kirkwood/board-lsxl.c
@@ -14,17 +14,9 @@
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/platform_device.h>
-#include <linux/mtd/partitions.h>
-#include <linux/ata_platform.h>
-#include <linux/spi/flash.h>
-#include <linux/spi/spi.h>
#include <linux/mv643xx_eth.h>
#include <linux/gpio.h>
#include <linux/gpio-fan.h>
-#include <linux/input.h>
-#include <asm/mach-types.h>
-#include <asm/mach/arch.h>
-#include <mach/kirkwood.h>
#include "common.h"
#include "mpp.h"
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/2] USB: Update EHCI-platform driver to devicetree.
From: Tony Prisk @ 2012-10-20 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1210201027280.24222-100000@netrider.rowland.org>
On Sat, 2012-10-20 at 10:31 -0400, Alan Stern wrote:
> On Sat, 20 Oct 2012, Florian Fainelli wrote:
>
> > Hi Tony,
> >
> > On Saturday 20 October 2012 16:17:32 Tony Prisk wrote:
> > > This patch adds devicetree support to the EHCI-platform driver,
> > > and removes the now unneeded ehci-vt8500.c
> > >
> > > Existing platform properties are maintained, with the exception
> > > the power_(on/off) and suspend function pointers.
> >
> > Ok, so I have recently sent a bit patchset to remove most OHCI/EHCI drivers
> > that could be converted to the generic variants, series starts here:
> > 1349701906-16481-1-git-send-email-florian at openwrt.org
> >
> > in this patchset I added a new property to the EHCI platform data:
> > need_io_watchdog, which needs to be handled too from DT ideally.
>
> Actually the new property is "no_io_watchdog". See
>
> http://marc.info/?l=linux-usb&m=134970247511140&w=2
>
> > Adding device tree bindings is on my TODO after having a generic way
> > to pass clocks to the ehci/ohci platform drivers, so you are right on time :)
>
> At some point we'll need a way to handle the power_{on,off,suspend}
> callbacks. I don't know how that should be done.
>
> Alan Stern
I actually included a comment in the patch regarding the missing
functions:
> + * No platform data is being passed, so initalize
> pdata.
> + * Limitation: we can't support power_on, power_off or
> + * power_suspend function pointers from DT.
> + * TODO: The missing functions could be replaced with
> + * power sequence handlers.
> + */
I don't know anything about the power sequence code, but have seen some
patches for pwm backlight using it. I don't know if it would allow
everything that's needed, but it seems to have support for voltage
regulators and gpios (among other things).
Regards
Tony P
^ permalink raw reply
* [PATCH v2 2/2] USB: doc: Binding document for ehci-platform driver
From: Tony Prisk @ 2012-10-20 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350771032-11527-1-git-send-email-linux@prisktech.co.nz>
Add a binding document for ehci-platform driver.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
.../devicetree/bindings/usb/ehci-platform.txt | 27 ++++++++++++++++++++
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/ehci-platform.txt
diff --git a/Documentation/devicetree/bindings/usb/ehci-platform.txt b/Documentation/devicetree/bindings/usb/ehci-platform.txt
new file mode 100644
index 0000000..930b19e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ehci-platform.txt
@@ -0,0 +1,27 @@
+Generic Platform EHCI Controller
+-----------------------------------------------------
+
+Required properties:
+- compatible : "linux,ehci-platform"
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : EHCI controller interrupt
+
+Optional properties:
+- caps-offset : offset to the capabilities register (default = 0)
+- has-tt : controller has transaction translator(s).
+- has-synopsys-hc-bug : controller has the synopsys hc bug
+- no-io-watchdog : controller does not need io watchdog
+
+- big-endian : descriptors and registers are both big endian. This
+ is the equivalent of specifying big-endian-desc and big-endian-regs.
+OR
+- big-endian-desc : descriptors are in big-endian format
+- big-endian-regs : mmio is in big-endian format
+
+Example:
+ ehci at d8007c00 {
+ compatible = "ehci-platform";
+ reg = <0xd8007c00 0x200>;
+ interrupts = <43>;
+ has-tt;
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/2] USB: Update EHCI-platform driver to devicetree.
From: Tony Prisk @ 2012-10-20 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350771032-11527-1-git-send-email-linux@prisktech.co.nz>
This patch adds devicetree support to the EHCI-platform driver,
and removes the now unneeded ehci-vt8500.c
Existing platform properties are maintained, with the exception
the power_(on/off) and suspend function pointers.
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
---
drivers/usb/host/ehci-hcd.c | 5 --
drivers/usb/host/ehci-platform.c | 61 +++++++++++++-
drivers/usb/host/ehci-vt8500.c | 171 --------------------------------------
include/linux/usb/ehci_pdriver.h | 1 +
4 files changed, 61 insertions(+), 177 deletions(-)
delete mode 100644 drivers/usb/host/ehci-vt8500.c
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 6bf6c42..42c8e84 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -1274,11 +1274,6 @@ MODULE_LICENSE ("GPL");
#define PLATFORM_DRIVER cns3xxx_ehci_driver
#endif
-#ifdef CONFIG_ARCH_VT8500
-#include "ehci-vt8500.c"
-#define PLATFORM_DRIVER vt8500_ehci_driver
-#endif
-
#ifdef CONFIG_PLAT_SPEAR
#include "ehci-spear.c"
#define PLATFORM_DRIVER spear_ehci_hcd_driver
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 764e010..f44fc6a 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -19,6 +19,7 @@
* Licensed under the GNU/GPL. See COPYING for details.
*/
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <linux/usb/ehci_pdriver.h>
static int ehci_platform_reset(struct usb_hcd *hcd)
@@ -78,14 +79,60 @@ static const struct hc_driver ehci_platform_hc_driver = {
.clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
};
+static u64 ehci_dma_mask = DMA_BIT_MASK(32);
+
static int __devinit ehci_platform_probe(struct platform_device *dev)
{
struct usb_hcd *hcd;
struct resource *res_mem;
struct usb_ehci_pdata *pdata = dev->dev.platform_data;
+ struct device_node *np = dev->dev.of_node;
int irq;
int err = -ENOMEM;
+ /* Are we being initialized from a DT-probed device? */
+ if (np) {
+ /*
+ * No platform data is being passed, so initalize pdata.
+ * Limitation: we can't support power_on, power_off or
+ * power_suspend function pointers from DT.
+ * TODO: The missing functions could be replaced with
+ * power sequence handlers.
+ */
+ pdata = devm_kzalloc(&dev->dev, sizeof(*pdata), GFP_KERNEL);
+ dev->dev.platform_data = pdata;
+
+ if (!pdata) {
+ pr_err("device tree platform data allocation failed\n");
+ return -ENOMEM;
+ }
+
+ /* Read the optional properties from DT node */
+ of_property_read_u32(np, "caps-offset", &pdata->caps_offset);
+ if (of_property_read_bool(np, "no_io_watchdog"))
+ pdata->no_io_watchdog = 1;
+ if (of_property_read_bool(np, "has-tt"))
+ pdata->has_tt = 1;
+ if (of_property_read_bool(np, "has-synopsys-hc-bug"))
+ pdata->has_synopsys_hc_bug = 1;
+
+ if (of_property_read_bool(np, "big-endian")) {
+ pdata->big_endian_desc = 1;
+ pdata->big_endian_mmio = 1;
+ } else {
+ if (of_property_read_bool(np, "big-endian-desc"))
+ pdata->big_endian_desc = 1;
+ if (of_property_read_bool(np, "big-endian-regs"))
+ pdata->big_endian_mmio = 1;
+ }
+ /* Right now device-tree probed devices don't get dma_mask set.
+ * Since shared usb code relies on it, set it here for now.
+ * Once we have dma capability bindings this can go away.
+ */
+ if (!dev->dev.dma_mask)
+ dev->dev.dma_mask = &ehci_dma_mask;
+ }
+
if (!pdata) {
WARN_ON(1);
return -ENODEV;
@@ -101,7 +148,7 @@ static int __devinit ehci_platform_probe(struct platform_device *dev)
}
res_mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
if (!res_mem) {
- pr_err("no memory recourse provided");
+ pr_err("no memory resource provided");
return -ENXIO;
}
@@ -163,6 +210,7 @@ static int __devexit ehci_platform_remove(struct platform_device *dev)
release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
platform_set_drvdata(dev, NULL);
+ devm_kfree(&dev->dev, pdata);
if (pdata->power_off)
pdata->power_off(dev);
@@ -215,6 +263,16 @@ static const struct platform_device_id ehci_platform_table[] = {
{ "ehci-platform", 0 },
{ }
};
+
+#ifdef CONFIG_OF
+static const struct of_device_id ehci_platform_ids[] = {
+ { .compatible = "linux,ehci-platform", },
+ {}
+};
+
+MODULE_DEVICE_TABLE(of, ehci_platform_ids);
+#endif
+
MODULE_DEVICE_TABLE(platform, ehci_platform_table);
static const struct dev_pm_ops ehci_platform_pm_ops = {
@@ -231,5 +289,6 @@ static struct platform_driver ehci_platform_driver = {
.owner = THIS_MODULE,
.name = "ehci-platform",
.pm = &ehci_platform_pm_ops,
+ .of_match_table = of_match_ptr(ehci_platform_ids),
}
};
diff --git a/drivers/usb/host/ehci-vt8500.c b/drivers/usb/host/ehci-vt8500.c
deleted file mode 100644
index d3c9a3e..0000000
--- a/drivers/usb/host/ehci-vt8500.c
+++ /dev/null
@@ -1,171 +0,0 @@
-/*
- * drivers/usb/host/ehci-vt8500.c
- *
- * Copyright (C) 2010 Alexey Charkov <alchark@gmail.com>
- *
- * Based on ehci-au1xxx.c
- *
- * This software is licensed under the terms of the GNU General Public
- * License version 2, as published by the Free Software Foundation, and
- * may be copied, distributed, and modified under those terms.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/of.h>
-#include <linux/platform_device.h>
-
-static int ehci_update_device(struct usb_hcd *hcd, struct usb_device *udev)
-{
- struct ehci_hcd *ehci = hcd_to_ehci(hcd);
- int rc = 0;
-
- if (!udev->parent) /* udev is root hub itself, impossible */
- rc = -1;
- /* we only support lpm device connected to root hub yet */
- if (ehci->has_lpm && !udev->parent->parent) {
- rc = ehci_lpm_set_da(ehci, udev->devnum, udev->portnum);
- if (!rc)
- rc = ehci_lpm_check(ehci, udev->portnum);
- }
- return rc;
-}
-
-static const struct hc_driver vt8500_ehci_hc_driver = {
- .description = hcd_name,
- .product_desc = "VT8500 EHCI",
- .hcd_priv_size = sizeof(struct ehci_hcd),
-
- /*
- * generic hardware linkage
- */
- .irq = ehci_irq,
- .flags = HCD_MEMORY | HCD_USB2,
-
- /*
- * basic lifecycle operations
- */
- .reset = ehci_setup,
- .start = ehci_run,
- .stop = ehci_stop,
- .shutdown = ehci_shutdown,
-
- /*
- * managing i/o requests and associated device resources
- */
- .urb_enqueue = ehci_urb_enqueue,
- .urb_dequeue = ehci_urb_dequeue,
- .endpoint_disable = ehci_endpoint_disable,
- .endpoint_reset = ehci_endpoint_reset,
-
- /*
- * scheduling support
- */
- .get_frame_number = ehci_get_frame,
-
- /*
- * root hub support
- */
- .hub_status_data = ehci_hub_status_data,
- .hub_control = ehci_hub_control,
- .bus_suspend = ehci_bus_suspend,
- .bus_resume = ehci_bus_resume,
- .relinquish_port = ehci_relinquish_port,
- .port_handed_over = ehci_port_handed_over,
-
- /*
- * call back when device connected and addressed
- */
- .update_device = ehci_update_device,
-
- .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
-};
-
-static u64 vt8500_ehci_dma_mask = DMA_BIT_MASK(32);
-
-static int vt8500_ehci_drv_probe(struct platform_device *pdev)
-{
- struct usb_hcd *hcd;
- struct ehci_hcd *ehci;
- struct resource *res;
- int ret;
-
- if (usb_disabled())
- return -ENODEV;
-
- /*
- * Right now device-tree probed devices don't get dma_mask set.
- * Since shared usb code relies on it, set it here for now.
- * Once we have dma capability bindings this can go away.
- */
- if (!pdev->dev.dma_mask)
- pdev->dev.dma_mask = &vt8500_ehci_dma_mask;
-
- if (pdev->resource[1].flags != IORESOURCE_IRQ) {
- pr_debug("resource[1] is not IORESOURCE_IRQ");
- return -ENOMEM;
- }
- hcd = usb_create_hcd(&vt8500_ehci_hc_driver, &pdev->dev, "VT8500");
- if (!hcd)
- return -ENOMEM;
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- hcd->rsrc_start = res->start;
- hcd->rsrc_len = resource_size(res);
-
- hcd->regs = devm_request_and_ioremap(&pdev->dev, res);
- if (!hcd->regs) {
- pr_debug("ioremap failed");
- ret = -ENOMEM;
- goto err1;
- }
-
- ehci = hcd_to_ehci(hcd);
- ehci->caps = hcd->regs;
-
- ret = usb_add_hcd(hcd, pdev->resource[1].start,
- IRQF_SHARED);
- if (ret == 0) {
- platform_set_drvdata(pdev, hcd);
- return ret;
- }
-
-err1:
- usb_put_hcd(hcd);
- return ret;
-}
-
-static int vt8500_ehci_drv_remove(struct platform_device *pdev)
-{
- struct usb_hcd *hcd = platform_get_drvdata(pdev);
-
- usb_remove_hcd(hcd);
- usb_put_hcd(hcd);
- platform_set_drvdata(pdev, NULL);
-
- return 0;
-}
-
-static const struct of_device_id vt8500_ehci_ids[] = {
- { .compatible = "via,vt8500-ehci", },
- { .compatible = "wm,prizm-ehci", },
- {}
-};
-
-static struct platform_driver vt8500_ehci_driver = {
- .probe = vt8500_ehci_drv_probe,
- .remove = vt8500_ehci_drv_remove,
- .shutdown = usb_hcd_platform_shutdown,
- .driver = {
- .name = "vt8500-ehci",
- .owner = THIS_MODULE,
- .of_match_table = of_match_ptr(vt8500_ehci_ids),
- }
-};
-
-MODULE_ALIAS("platform:vt8500-ehci");
-MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
diff --git a/include/linux/usb/ehci_pdriver.h b/include/linux/usb/ehci_pdriver.h
index c9d09f8..e9f74fa 100644
--- a/include/linux/usb/ehci_pdriver.h
+++ b/include/linux/usb/ehci_pdriver.h
@@ -41,6 +41,7 @@ struct usb_ehci_pdata {
unsigned big_endian_mmio:1;
unsigned port_power_on:1;
unsigned port_power_off:1;
+ unsigned no_io_watchdog:1;
/* Turn on all power and clocks */
int (*power_on)(struct platform_device *pdev);
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox