public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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