From: Dave Stevenson <dave.stevenson@raspberrypi.org>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Peter Robinson <pbrobinson@gmail.com>,
devel@driverdev.osuosl.org, tuomas.tynkkynen@iki.fi,
Greg KH <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org,
"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE"
<linux-rpi-kernel@lists.infradead.org>,
Dan Carpenter <dan.carpenter@oracle.com>,
nsaenzjulienne@suse.de
Subject: Re: [PATCH 0/7] staging: vc04_services: Some dead code removal
Date: Mon, 29 Oct 2018 10:43:46 +0000 [thread overview]
Message-ID: <CAAoAYcO293gnvk5cYeNR=wiA6Waq2h=buC0hSGzEbCOMwT4teg@mail.gmail.com> (raw)
In-Reply-To: <1503865704.281328.1540715494361@email.1und1.de>
Hi Stefan
On Sun, 28 Oct 2018 at 08:31, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> Hi Dave,
>
> > Dave Stevenson <dave.stevenson@raspberrypi.org> hat am 26. Oktober 2018 um 19:15 geschrieben:
> >
> >
> > Thanks Stefan.
> > I've picked up your latest patches which mean I can get the driver
> > loaded via the (almost) approved method.
> > I do seem to still have issues with not getting the expected address
> > ranges, so the driver/VPU was trying to map cached alias memory. As
> > your patches only came through yesterday I haven't had a chance to dig
> > through why yet. I've done a temporary hack to ensure we always map
> > the uncached alias, but that can't persist.
>
> does it mean with DT probing it worked before and with platform change it's broken?
> Or anything else cause this regression in 4.19?
Yes, probing via DT with the node under soc gave me the correct DMA
addresses (uncached alias). With the platform changes I get the cached
alias.
Both were under 4.14. I'll try again on a later branch.
> > The networking issue has been resolved :-)
> >
> > I've pushed where I've got to to
> > https://github.com/6by9/linux/tree/rpi-4.14.y-codecs-push-pt2b
> > It's a touch messy due to integrating in your patches in the last 24
> > hours. It needs a full rebase so that my changes are on top of yours
> > rather than haphazard.
> > As we're moving to 4.19 fairly soon I may well abandon my 4.14 tree
> > and jump to either that or directly on staging. I'll see where I get
> > to early next week.
>
> Sorry, but there is no need for a quick shot against a downstream 4.14. I assumed you make your changes against upstream linux-next + Phil's and my patches.
>
> You can use https://github.com/anholt/linux/commits/bcm2835-audio until 4.20-rc1 is out.
> Using 4.14 or 4.19 doesn't make any sense to me.
As an employee of Raspberry Pi Trading my first responsibilty is to
them, and that means LTS releases feeding in to the downstream kernel.
If these drivers can be pushed upstream then that's a win as it avoids
divergence, but it is not my main goal. At least 4.19 and 4.20 aren't
far apart so there are likely to be fewer differences.
I had it all working on 4.14, therefore it made sense to see whether
your changes allowed me to load as a platform driver. It did, but with
this little niggle over cache aliases. I'll try again on a later
kernel and try to get some more info.
Dave
prev parent reply other threads:[~2018-10-29 10:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-04 9:37 [PATCH 0/7] staging: vc04_services: Some dead code removal Tuomas Tynkkynen
2018-10-04 9:37 ` [PATCH 1/7] staging: vc04_services: Drop pointless stub functions Tuomas Tynkkynen
2018-10-04 9:37 ` [PATCH 2/7] staging: vc04_services: Drop 'connection' field from SERVICE_CREATION_T Tuomas Tynkkynen
2018-10-04 9:37 ` [PATCH 3/7] staging: vc04_services: Drop trivially unused fields " Tuomas Tynkkynen
2018-10-04 9:37 ` [PATCH 4/7] staging: vc04_services: Drop declaration of vchi_crc_control() Tuomas Tynkkynen
2018-10-04 9:37 ` [PATCH 5/7] staging: vc04_services: Drop VCHI_SERVICE_INIT and SERVICE_INFO_T Tuomas Tynkkynen
2018-10-04 9:37 ` [PATCH 6/7] staging: vc04_services: Drop unused parameters from vchi_connect() Tuomas Tynkkynen
2018-10-04 9:37 ` [PATCH 7/7] staging: vc04_services: Drop no longer needed headers Tuomas Tynkkynen
2018-10-06 10:18 ` [PATCH 0/7] staging: vc04_services: Some dead code removal Stefan Wahren
2018-10-15 16:14 ` Eric Anholt
2018-10-17 9:55 ` Dave Stevenson
2018-10-17 10:50 ` Stefan Wahren
2018-10-17 10:18 ` Dan Carpenter
2018-10-17 15:37 ` Eric Anholt
2018-10-17 16:51 ` Peter Robinson
2018-10-18 9:22 ` Dave Stevenson
2018-10-18 9:37 ` Stefan Wahren
2018-10-26 17:15 ` Dave Stevenson
2018-10-28 8:31 ` Stefan Wahren
2018-10-29 10:43 ` Dave Stevenson [this message]
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='CAAoAYcO293gnvk5cYeNR=wiA6Waq2h=buC0hSGzEbCOMwT4teg@mail.gmail.com' \
--to=dave.stevenson@raspberrypi.org \
--cc=dan.carpenter@oracle.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=nsaenzjulienne@suse.de \
--cc=pbrobinson@gmail.com \
--cc=stefan.wahren@i2se.com \
--cc=tuomas.tynkkynen@iki.fi \
/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;
as well as URLs for NNTP newsgroup(s).