From: Ben Dooks <ben.dooks@codethink.co.uk>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: linux-pci@vger.kernel.org, SH-Linux <linux-sh@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Valentine Barshak <valentine.barshak@cogentembedded.com>,
"Simon Horman [Horms]" <horms@verge.net.au>,
Bjorn Helgaas <bhelgaas@google.com>
Subject: Re: [PATCH 00/04] PCI: rcar: Driver model and physical address space update
Date: Wed, 05 Feb 2014 10:12:27 +0000 [thread overview]
Message-ID: <52F20E8B.4070108@codethink.co.uk> (raw)
In-Reply-To: <CANqRtoRUWC5ioDXJdEM6utQo2uHB3xar3RHzapR--xhjRmRQag@mail.gmail.com>
On 05/02/14 09:40, Magnus Damm wrote:
> On Wed, Feb 5, 2014 at 6:25 PM, Ben Dooks <ben.dooks@codethink.co.uk> wrote:
>> On 05/02/14 09:00, Magnus Damm wrote:
>>>
>>> Hi Ben,
>>
>>
>> [snip]
>>
>>> I think we should try to pick out the stuff that is ready to be merged
>>> first. I think these patches may require a bit of time before people
>>> start looking at them. I don't mind resending in the future.
>>>
>>> To be honest, I have not been paying too much attention to other
>>> patches including yours - been focused trying to get the memory
>>> management part right.. So I'd like to focus on correctness over DT
>>> for now if possible. Of course we it all.
>>>
>>> Would it be possible for you to provide a list of pci-rcar-gen2.c
>>> patches that you posted? Or perhaps you can resend your series and
>>> include acks that you received?
>>
>>
>> I don't think I have any acks, only review comments. I think the code
>> itself is pretty much ready to be merged and has been tested here with
>> the Lager board.
>
> Ok, thanks. I'd like to go through them myself if possible. I was
> looking for a cover letter or something that listed the patches but I
> can't seem to find it. Can you please provide a list?
I will re-send the patches once I've applied the relevant fixups from
the last round, hopefully within the next few hours.
>> The big issue for us is that we /must/ boot with fdt, which means the
>> less fdt support that is in the kernel then the more patches we end up
>> carrying out of tree. This is why we have been pushing patches out to
>> try and get the support in.
>
> Can you please define "boot with fdt"? As you probably know, both
> board-lager.c and board-lager-reference.c boot with DT. I suppose you
> mean that you want DT to describe the entire system, with no C code
> for the board? Please note that some devices like timers still don't
> use DT, so if you can live without those then... =)
We currently have enough to use the system. And yes, we boot with
board-lager-reference.c which current seems to be turning up bugs
in the up-stream (see the recent new bug with cpg clock code reported
by my colleague).
Due to issues out of our control we can test with board-lager.c but
we must use the board-lager-reference.c for actual product test. The
only way we found around this is ugly hacking of the core driver code
to link platform and fdt devices...
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
next prev parent reply other threads:[~2014-02-05 10:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-05 6:52 [PATCH 00/04] PCI: rcar: Driver model and physical address space update Magnus Damm
2014-02-05 6:52 ` [PATCH 01/04] PCI: rcar: Register each instance independently Magnus Damm
2014-02-05 8:02 ` Geert Uytterhoeven
2014-02-05 8:39 ` Magnus Damm
2014-02-05 8:29 ` Ben Dooks
2014-02-05 8:43 ` Magnus Damm
2014-02-05 6:53 ` [PATCH 02/04] PCI: rcar: Break out window size handling Magnus Damm
2014-02-05 6:53 ` [PATCH 03/04] PCI: rcar: Add DMABOUNCE support Magnus Damm
2014-02-05 6:53 ` [PATCH 04/04] PCI: rcar: Enable BOUNCE in case of HIGHMEM Magnus Damm
2014-02-05 8:33 ` [PATCH 00/04] PCI: rcar: Driver model and physical address space update Ben Dooks
2014-02-05 9:00 ` Magnus Damm
2014-02-05 9:25 ` Ben Dooks
2014-02-05 9:40 ` Magnus Damm
2014-02-05 10:12 ` Ben Dooks [this message]
2014-02-12 20:59 ` Bjorn Helgaas
2014-02-13 4:37 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52F20E8B.4070108@codethink.co.uk \
--to=ben.dooks@codethink.co.uk \
--cc=bhelgaas@google.com \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=valentine.barshak@cogentembedded.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox