09:26 < Marex> so I can probably ask now ... does anyone still care about retaining SH2/SH3 in U-Boot ? I'd like to remove those and only keep SH4/SH4A, since the SH2/SH3 were not updated for years
09:26 < wsa> thanks for the IO meeting!
09:26 < geertu> wsa: thx!
09:26 < wsa> Marex: is it in the way somehow?
09:27 < Marex> wsa: they were not converted to any of the modern frameworks and spew warnings in the build, which are unlikely to be ever fixed
09:28 < wsa> Marex: okay, i see, still using old frameworks is "in the way"
09:28 < damm> how much is a j-core board?
09:29 < Marex> damm: you can probably put it into an FPGA
09:29 < damm> ok sure, i was just hoping something turn-key existed
09:29 < Marex> damm: but I'd much rather reduce the number of boards and CPUs we support first, get the small(er) code into shape and only then add new boards
09:29 < damm> i recall they were doing sh2
09:29 < morimoto> Marex: I talked it with Goda-san this morning. Renesas BSP is using UBoot from many years ago, but when "SH Generation
09:30 < morimoto> Oops
09:30 < damm> Marex: if you prefer to rip stuff out then that's fine with me
09:31 < Marex> damm: I do, the SH2 CPU part is small and can be re-added easily if anyone cares
09:31 < morimoto> when "SH Generation" BSP, it is of course using Uboot, but very BSP-UBoot. We tried to upstream, but not super match. Renesas user still using these old board today, but there are using BSP-U-boot, not upstream-U-boot.
09:31 < Marex> damm: the bulk of the stuff I plan to nuke are boards, which I doubt anyone tested since forever
09:32 < Marex> morimoto: well ... what shall we do ?
09:32 < morimoto> It means, "up to you" :)
09:33 < damm> morimoto: do you have a list of SH-based boards that are in-use?
09:33 < Marex> morimoto: I saw iwamatsu-san did a great job on those SH platforms, but that was years ago :(
09:33 < geertu> Marex: Have you asked Iwamatsu-san?
09:33 < morimoto> Renesas side doesn't get damage if SH2/SH3 were removed, I mean
09:33 < shimoda> http://oss.renesas.com/ ?
09:33 < Marex> it seems debian is still using some SH4 boards
09:33 < geertu> He may have a more educated opinion
09:33 < shimoda> it seems sh4 base only
09:34 < Marex> shimoda: ah, so if we keep SH4, it should be OK ?
09:34 < kbingham> damm, I have a numato which runs the SH2 (J2)
09:35 < Marex> kbingham: great, would you like to upstream it ? :)
09:35 < geertu> J2 is DT based, so all modern?
09:35 < Marex> geertu: mimas v2 is, which is J2
09:36 < Marex> geertu: the only DT-based SH board I think
09:36 < shimoda> Marex: i think so
09:36 < geertu> http://oss.renesas.com/Documentations/Kernel_TODO_List.pdf
09:36 < kbingham> I believe there is kernel support upstream for J2, Rich Felker upstreamed it I think ...
09:36 < Marex> shimoda: OK, let's do that
09:37 < damm> kbingham: can you use JTAG on that somehow?
09:37 < Marex> shimoda: and since I can start code on the SH4A core in R-Car Gen2 , I might add some of those boards as SH4A targets too, which in turn would help us retain SH4A in for a bit longer
09:39 < geertu> Let's start the Core meeting after the first Core question ;-)
09:39 < geertu> Welcome to Today's Core Group Chat!
09:39 < geertu> Agenda:
09:39 < geertu> 1. Status Updates
09:39 < geertu> 2. Discussion Topics
09:39 < geertu> Topic 1. Status updates
09:39 < geertu> A) What have we done since last time:
09:39 < geertu> Marek worked on ATF (BSP v2.0.3 upstreaming), OpenOCD (RPC HF and SH
09:39 < geertu> QSPI), and U-Boot (GPIO, PFC, GR-Peach, SH2/SH3 removal).
09:39 < geertu> Morimoto-san fought with Renesas about our budget.
09:39 < geertu> Niklas updated copyright in rcar-dmac.
09:39 < geertu> Geert sent clock and pin control pull requests for v5.2, enjoyed
09:39 < geertu> holidays, posted IPMMU suspend/resume and PFC validation patches, wrote
09:39 < geertu> a driver for the RZ/A1 IRQC, and enabled TPU pin groups on R-Car
09:39 < geertu> H3/M3-W/M3-N.
09:39 < kbingham> damm, on the Numato board? Hrm ... not sure. I thnik the the fpga is programmed over jtag - not sure what happens after that :)
09:40 < Marex> kbingham: can you JTAG the SH2 core ? Maybe ask in #j-core ;-)
09:40 < Marex> kbingham: or at least read the backlog
09:40 < kbingham> Marex, Can the SH4a be set up with rproc framework?
09:40 < damm> kbingham: ok, thanks =)
09:40 < kbingham> (sorry - I'll let geertu continue now)
09:42 < geertu> kbingham: https://marc.info/?l=linux-sh&m=130034400711357
09:42 < geertu> B) What we plan to do till next time:
09:42 < geertu> Marek plans to submit SH2/SH3 removal patches for U-Boot.
09:42 < geertu> Geert wants to finish on-going sh-pfc non-GPIO-pin cleanup.
09:43 < geertu> C) Problems we have currently:
09:43 < geertu> Marek wonders if anyone still cares about SH2/SH3 and SH4/SH4A boards in
09:43 < geertu> U-Boot.
09:43 < geertu> Morimoto-san was shocked by Magnus hurting his leg.
09:43 < geertu> EOT
09:43 < geertu> Anything I missed?
09:43 < Marex> kbingham: didn't we discuss that somewhere yet ? maybe it was something I discussed with damm -san . Yep, for starters, remoteproc in U-Boot would be good to bootstrap U-Boot on that SH4A core ; remoteproc in Linux, hum, maybe ; but once the U-Boot is in decent shape, I'd like to boot it natively by flipping MD7
09:44 < Marex> geertu: I worked on ATF ? :)
09:45 < Marex> geertu: I dont see it in my current report from yesterday
09:45 < geertu> Marex: Since last meeting, i.e. 2019-04-04
09:45 < geertu> So I combined with the 2019-04-18 report, when there was no meeting
09:46 < Marex> geertu: ah, OK
09:47 < geertu> Topic 2. Discussion Topics
09:47 < geertu> Looks like SH* removal from U-BOot has received some discussion already
09:48 < geertu> Anything to be added?
09:48 < Marex> ah
09:48 < shimoda> i have a question about coresight as I sent an email.
09:48 < Marex> morimoto: shimoda: are r-car gen2 or r-car gen3 BSDL files (for boundary scan testing) available somewhere ?
09:49 < shimoda> do you know how to use the linux coresight framework? maybe no? :)
09:49 < kbingham> Marex, haha bootloader guys "We'll boot the core in the bootloader" : Linux guys "We'll boot the core in linux" :D
09:49 < Marex> shimoda: I had a vague look into it as some point, what do you plan to do with it ?
09:50 < geertu> I haven't used the linux coresight framework yet
09:50 < Marex> geertu: i did on socfpga, it can do way too many things and is convoluted as heck
09:52 < geertu> I'm also wondering if "Chapter 85. Debug and Trace" contains sufficient information to describe everything in DT, as per Documentation/devicetree/bindings/arm/coresight.txt
09:54 < shimoda> Marex: i searched the internal sharepoint and then i found r8a7796 bsdl file. But, I don't know I can export it to you.
09:57 < Marex> shimoda: ah, all right, does it contain the MD pins on the IO chain ? :)
09:57 < Marex> shimoda: I wonder if we could somehow use BST to simulate toggling MD pins over JTAG
09:58 < geertu> Marex: The MD pins are sampled ay reset time
09:58 < Marex> shimoda: then we won't need any of those remote-setup MD-pin toggling contraptions, but only a JTAG probe
09:58 < Marex> geertu: reset time of what ? the CPU core ?
09:58 < geertu> But you mean their internal state may be accessable on the chain?
09:58 < Marex> geertu: hold the CPU in reset, do your BST setup, EXTEST, release CPU from reset
09:58 < geertu> System reset time
09:59 < geertu> Which CPU core? There are many ;-)
09:59 < wsa> shimoda: no coresight experience here, I am sorry
09:59 < Marex> geertu: the boot CPU
10:00 < Marex> geertu: some of the MD pins are sampled either by the bootrom or only be the ATF, so I dont think they are necessarily all used at _system_ reset time
10:00 < geertu> Marex: "[MODEMR] register is initialized only by PRESET#"
10:00 < Marex> geertu: the ones which are used to select boot mode are probably sampled by bootrom, so if you can flip them via JTAG, you can put the CPU into SCIF loader mode and then use that to unblock RPC access and reflash the board
10:01 < shimoda> Marex: i greped "MD" and "MODE" in the bsdl file but it doesn't seems to contain them
10:02 < geertu> shimoda: For now, I'll add CoreSight as a task to periject
10:02 < Marex> shimoda: hum :(
10:02 < damm> shimoda: i think you should grep for something else. the MD pins are shared with data or address lines, so A or D would make more sense
10:02 < Marex> shimoda: I wonder what lauterbach does in their debug probe to unlock the RPC
10:03 < Marex> shimoda: it would seem that the ADIT people somehow use the lauterbach probe to unlock RPC and reflash the ATF/U-Boot on the Gen3 boards and that it just works (TM)
10:03 < Marex> shimoda: maybe there's some sort of a trick to it
10:04 < shimoda> Marex: geertu: wsa: about coresight, thank you for the reply. just i would like to know who have some experience for it. now i will reply to BSP team that upstream team have never tried the coresight framework for now
10:05 < Marex> shimoda: I tried the CTI, on a different SoC, but not more than that
10:06 < geertu> OK
10:07 < geertu> Anything else to discuss? We've entered the MultiMedia space/time continuum
10:07 < pinchartl> geertu: next meeting date ?
10:08 < Marex> geertu: the final frontier ?
10:08 < geertu> pinchartl: wsa: In 2 weeks? Or 4 weeks? (3 weeks is public holiday in most of EU)
10:09 < pinchartl> 2 weeks seems good to me
10:09 < pinchartl> in 3 weeks I won't be available
10:10 < wsa> 2 weeks
10:10 < geertu> 2 weeks is fine for me
10:10 < geertu> All set?
10:10 < geertu> Thanks for joining, and have a nice continued day!
obtaining a
* copy of this software and associated documentation files (the
* "Software"), to deal in the Software without restriction, including
* without limitation the rights to use, copy, modify, merge, publish,
* distribute, sub license, and/or sell copies of the Software, and to
* permit persons to whom the Software is furnished to do so, subject to
* the following conditions:
*
* The above copyright notice and this permission notice (including the
* next paragraph) shall be included in all copies or substantial portions
* of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
* THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
* DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
* OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
* USE OR OTHER DEALINGS IN THE SOFTWARE.
*
**************************************************************************/
/*
* Authors: Thomas Hellström <thomas-at-tungstengraphics-dot-com>
*/
/*
* This file implements a simple replacement for the buffer manager use
* of the heavyweight hardware lock.
* The lock is a read-write lock. Taking it in read mode is fast, and
* intended for in-kernel use only.
* Taking it in write mode is slow.
*
* The write mode is used only when there is a need to block all
* user-space processes from allocating a
* new memory area.
* Typical use in write mode is X server VT switching, and it's allowed
* to leave kernel space with the write lock held. If a user-space process
* dies while having the write-lock, it will be released during the file
* descriptor release.
*
* The read lock is typically placed at the start of an IOCTL- or
* user-space callable function that may end up allocating a memory area.
* This includes setstatus, super-ioctls and no_pfn; the latter may move
* unmappable regions to mappable. It's a bug to leave kernel space with the
* read lock held.
*
* Both read- and write lock taking may be interruptible for low signal-delivery
* latency. The locking functions will return -EAGAIN if interrupted by a
* signal.
*
* Locking order: The lock should be taken BEFORE any kernel mutexes
* or spinlocks.
*/
#include "drmP.h"
void drm_bo_init_lock(struct drm_bo_lock *lock)
{
DRM_INIT_WAITQUEUE(&lock->queue);
atomic_set(&lock->write_lock_pending, 0);
atomic_set(&lock->readers, 0);
}
void drm_bo_read_unlock(struct drm_bo_lock *lock)
{
if (atomic_dec_and_test(&lock->readers))
wake_up_all(&lock->queue);
}
EXPORT_SYMBOL(drm_bo_read_unlock);
int drm_bo_read_lock(struct drm_bo_lock *lock, int interruptible)
{
while (unlikely(atomic_read(&lock->write_lock_pending) != 0)) {
int ret;
if (!interruptible) {
wait_event(lock->queue,
atomic_read(&lock->write_lock_pending) == 0);
continue;
}
ret = wait_event_interruptible
(lock->queue, atomic_read(&lock->write_lock_pending) == 0);
if (ret)
return -EAGAIN;
}
while (unlikely(!atomic_add_unless(&lock->readers, 1, -1))) {
int ret;
if (!interruptible) {
wait_event(lock->queue,
atomic_read(&lock->readers) != -1);
continue;
}
ret = wait_event_interruptible
(lock->queue, atomic_read(&lock->readers) != -1);
if (ret)
return -EAGAIN;
}
return 0;
}
EXPORT_SYMBOL(drm_bo_read_lock);
static int __drm_bo_write_unlock(struct drm_bo_lock *lock)
{
if (unlikely(atomic_cmpxchg(&lock->readers, -1, 0) != -1))
return -EINVAL;
wake_up_all(&lock->queue);
return 0;
}
static void drm_bo_write_lock_remove(struct drm_file *file_priv,
struct drm_user_object *item)
{
struct drm_bo_lock *lock = container_of(item, struct drm_bo_lock, base);
int ret;
ret = __drm_bo_write_unlock(lock);
BUG_ON(ret);
}
int drm_bo_write_lock(struct drm_bo_lock *lock, int interruptible,
struct drm_file *file_priv)
{
int ret = 0;
struct drm_device *dev;
atomic_inc(&lock->write_lock_pending);
while (unlikely(atomic_cmpxchg(&lock->readers, 0, -1) != 0)) {
if (!interruptible) {
wait_event(lock->queue,
atomic_read(&lock->readers) == 0);
continue;
}
ret = wait_event_interruptible
(lock->queue, atomic_read(&lock->readers) == 0);
if (ret) {
atomic_dec(&lock->write_lock_pending);
wake_up_all(&lock->queue);
return -EAGAIN;
}
}
/*
* Add a dummy user-object, the destructor of which will
* make sure the lock is released if the client dies
* while holding it.
*/
if (atomic_dec_and_test(&lock->write_lock_pending))
wake_up_all(&lock->queue);
dev = file_priv->minor->dev;
mutex_lock(&dev->struct_mutex);
ret = drm_add_user_object(file_priv, &lock->base, 0);
lock->base.remove = &drm_bo_write_lock_remove;
lock->base.type = drm_lock_type;
if (ret)
(void)__drm_bo_write_unlock(lock);