Hi,
everything you want is already available and on the way to mainline
concerning support for various FPGA loading modes or available for
checkout from a git repository.
All that has already been discussed on the mailing list.
FPGA loading interface is available here [1].
Patchset missing fo
Hello Alan,
Am 07.11.2018 18:51, schrieb Alan Tull:
Hi Greg,
Please take these four small fpga fixes patches. They
have been reviewed on the mailing list and apply
cleanly on current linux-next and char-misc-testing.
Thanks,
Alan
Anatolij Gustschin (1):
fpga: altera-cvp: fix 'bad IO access'
Hi Andreas,
Am 22.10.2018 15:15, schrieb Andreas Puhm:
Hi Moritz,
Thank you, for your fast response!
Below you can find the updated patch.
Full description:
The altera_cvp probe function only checks,
if the Altera/Intel PCI
.2017 16:16, schrieb Alan Tull:
On Wed, Aug 2, 2017 at 6:36 AM, Eric Schwarz
wrote:
Dear all,
DENX Software Engineering develops and brings this driver to mainline
on
behalf of us (ARRI*).
Since there was a lot of discussion around this patch series I would
highly
appreciate if someone
Dear all,
DENX Software Engineering develops and brings this driver to mainline on
behalf of us (ARRI*).
Since there was a lot of discussion around this patch series I would
highly appreciate if someone could sum up what needs to be changed in
detail in order to get this driver into the main
Hi,
I'll agree with Karl and Doug. If you (as a board vendor/maintainer/etc) want
to use I2C, it's *your* responsibility to provide the pullup resistors by
either including pullup resistors on the board or by enabling the internal
ones.
Either way, you should think a moment about the consequenc
he LOW period of the scl clock.
>
> Thanks Doug for the suggestion about division formulas.
>
> Tested-by: Heiko Stuebner
> Reviewed-by: Doug Anderson
> Tested-by: Doug Anderson
> Signed-off-by: Addy Ke
Reviewed-by: Max Schwarz
Tested-by: Max Schwarz
Cheers,
Hi Addy,
On Monday 13 October 2014 at 10:44:04, Addy Ke wrote:
> As show in I2C specification:
> - Standard-mode: the minimum HIGH period of the scl clock is 4.0us
> the minimum LOW period of the scl clock is 4.7us
> - Fast-mode: the minimum HIGH period of the scl clock is 0.6us
>
Hi Addy,
sorry for the long delay, I finally had time to look at your work.
On Thursday 09 October 2014 at 14:47:15, Addy Ke wrote:
> As show in I2C specification:
> - Standard-mode: the minimum HIGH period of the scl clock is 4.0us
> the minimum LOW period of the scl clock is 4.
ssed == 0 && cnt == 0)
Yes, looks correct and makes i2cdetect work for me on Radxa Rock.
Reviewed-By: Max Schwarz
Tested-By: Max Schwarz
Cheers,
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ol.
I'm sorry, I see now that subsys_initcall() gets mapped to module_init() if
the driver is built as a loadable module. Everything is fine ;-)
Acked-By: Max Schwarz
Cheers,
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
Hi Chris,
Am Montag, 22. September 2014, 15:24:35 schrieb Chris Zhong:
> Some device using this bus, such as regulators, they should register
> as early as possible, so the I2C bus master needs to be loaded early.
> Therefore initialize via subsys_initcall() is better.
You could also use probe de
thing and trigger an additional chunk read if
necessary:
/* are we finished? */
if (i2c->processed == i2c->msg->len)
rk3x_i2c_stop(i2c, i2c->error);
else
rk3x_i2c_prepare_read(i2c);
I'd like a clearer syntax as suggested by Sergei, though.
Apart from that,
Acked-By: Max Schwarz
Cheers,
Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting
Hi Wolfram,
thanks for your comments.
On Tuesday 10 June 2014 at 21:27:09, Wolfram Sang wrote:
> Checking if the spinlock is needed would be nice, but we can also fix
> this later.
I'm simply not sure about the spinlock. My knowledge about IRQ handling in
linux is limited.
We have an SMP syste
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
Sorry for the resend, I forgot to CC the developers at Rockchip
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting
Hi Wolfram,
thanks for the review!
> > +
> > + /* Settings */
> > + unsigned int scl_frequency;
> > +
> > + /* Synchronization & notification */
> > + spinlock_t lock;
>
> Why the lock? The core has per-adapter locks anyhow.
I'm using it to lock the rk3x_i2c struct during interrupts. It
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Signed-off-by: Max Schwarz
---
The driver cannot be used without a proper clock driver
supporting
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Tested on the Radxa Rock board, which is based on RK3188.
Signed-off-by: Max Schwarz
---
changes
Hello Heiko,
thanks for your comments.
> both the grf as well as the bus-idx are rockchip specific, so they should be
> prefixed (rockchip,grf, etc) and from my personal taste I would hope we
> could invest in an "n" and "e", to make it a full bus-index ;-)
I will change the names to rockchip,grf
Driver for the native I2C adapter found in Rockchip RK3xxx SoCs.
Configuration is only possible through devicetree. The driver is
interrupt driven and supports the I2C_M_IGNORE_NAK mangling bit.
Tested on the Radxa Rock board, which is based on RK3188.
Signed-off-by: Max Schwarz
---
For
The MAC address retrieved from dt was not actually written to the
hardware. This meant proper communication was only possible after
changing the MAC address.
Fix that by always writing the mac address during probing.
Signed-off-by: Max Schwarz
---
I recently noticed this problem on the Radxa
];
dma = ints[3];
dma16 = ints[4];
+ mpu_io = ints[5];
return 1;
}
I could not find any documentation that would mention sb=, let alone its
parameters. If that one exists nonetheless it would of course also have to be
complemented.
Georg
--
Georg Schwarz
kernel: Symbols match kernel version 2.4.21.
Apr 8 08:40:25 dslxs01neu kernel: Loaded 588 symbols from 21 modules.
The machine is still up and running, but 'Kernel panic' seems to be
something serious ;-)
Can some tell me what these messages mean ?
Thanks a lot,
Marco Schwarz
-
To unsubs
Hi everyone,
since 2.4.29 we discovered a strange behaviour.
Severall tasks are no longer detected as destroyed.
means, these tasks have ended but arn't removed from
the processlist.
An example from today:
[EMAIL PROTECTED] ]# date
Mon Feb 21 10:14:06 CET 2005
[EMAIL PROTECTED] ]# strace -p 3
On Wed, Jan 10, 2001 at 09:21:57PM -0200, Marcelo Tosatti wrote:
>> kernel BUG at vmscan.c:452!
>> invalid operand:
> Does reiserfs patch changes vmscan.c ?
No, it doesn't.
It's strange that the console reported vmscan.c:452 whilst
kern.log reports page_alloc.c:74
So long.
Ulrich
-
To u
2.4.0 (final i586) patched with reiserfs 3.6.25 produced the following BUG:
the console report (ksymoopsed):
kernel BUG at vmscan.c:452!
invalid operand:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 001c ebx: c101322c ecx: c0274
Hi,
2.4.0 (final i386) patched with reiserfs 3.6.25 produced the following BUG:
the console reported:
kernel BUG at vmscan.c:452!
invalid operand:
CPU:0
EIP:0010:[]
EFLAGS: 00010282
eax: 001c ebx: c101322c ecx: c0274608 edx:
esi: c23acc24 edi: c1013210 ebp: 00
30 matches
Mail list logo
