Hi Mark!
> On 23.01.2019, at 18:56, Mark Brown wrote:
>
>> On Sun, Jan 20, 2019 at 12:24:23PM +0100, ker...@martin.sperl.org wrote:
>>
>> These kind of changes it requires are consuming a bit more time than
>> I was hoping for.
>
> Thanks for trying.
>
>> So maybe at this very moment the best
> On 15.01.2019, at 20:26, Mark Brown wrote:
>
>> On Tue, Jan 15, 2019 at 06:39:27PM +0100, ker...@martin.sperl.org wrote:
>>
>> Is it possible that the specific flash is not using the “normal”
>> spi_pump_message, but spi_controller_mem_ops operations?
>
> Right, that's my best guess at th
ycle when the at24 driver tries and retries the next write.
> Only a handful drivers use dev_err() on transfer error, so switch to
> dev_dbg() instead.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Martin Sperl
And I remember having had some discussions around this subject
with Phil Elwell or popcornmix some time ago on github where it boiled
down to: what is the "right" interface? - I can not find the reference
right now)
Reviewed-by: Martin Sperl
Thanks, Martin
> On 27 Sep 2016, at 13:57, Noralf Trønnes wrote:
>
> Writing to an AT24C32 generates on average 2x i2c transfer errors per
> 32-byte page write. Which amounts to a lot for a 4k write. This is due
> to the fact that the chip doesn't respond during it's internal write
> cycle when the at24 driver
On 20.09.2016 10:41, Noralf Trønnes wrote:
Den 20.09.2016 09:19, skrev Martin Sperl:
Hi Noralf!
On 19.09.2016 17:26, Noralf Trønnes wrote:
Some SMBus protocols use Repeated Start Condition to switch from write
mode to read mode. Devices like MMA8451 won't work without it.
When downs
.
Signed-off-by: Noralf Trønnes
Reviewed-by: Martin Sperl
Hi Noralf!
On 19.09.2016 17:26, Noralf Trønnes wrote:
Some SMBus protocols use Repeated Start Condition to switch from write
mode to read mode. Devices like MMA8451 won't work without it.
When downstream implemented support for this in i2c-bcm2708, it broke
support for some devices, so a module
clock's parent as critical
> clk: bcm2835: Skip PLLC clocks when deciding on a new clock parent
>
> drivers/clk/bcm/clk-bcm2835.c | 63 +--
> 1 file changed, 61 insertions(+), 2 deletions(-)
Whole series:
Acked-by: Martin Sperl
Note tha
> On 12.05.2016, at 20:15, Eric Anholt wrote:
>
> ker...@martin.sperl.org writes:
>
>> From: Martin Sperl
>>
>> As the sdram clock is a critical clock to the system
>> the minimal bcm2835-sdram driver claims (and enables)
>> this clock and also ex
> On 12.05.2016, at 17:55, Stefan Wahren wrote:
>
> Hi,
>
>> Martin Sperl hat am 12. Mai 2016 um 17:28
>> geschrieben:
>>
>>
>>
>>> On 12.05.2016, at 16:50, Stefan Wahren wrote:
>>>
>>> Hi Martin,
>&
> On 12.05.2016, at 16:56, Stefan Wahren wrote:
>
> Hi,
>
>> ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
>>
>>
>> From: Martin Sperl
>>
>> Add the bcm2835 sdram controller to the device tree.
>>
>> Signed-of
> On 12.05.2016, at 16:50, Stefan Wahren wrote:
>
> Hi Martin,
>
>> ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
>>
>>
>> From: Martin Sperl
>>
>> As the sdram clock is a critical clock to the system
>> the min
> On 11.05.2016, at 10:21, Martin Sperl wrote:
>
> On 10.05.2016, at 21:58, Martin Sperl wrote:
>>
>>
>>
>>> On 10.05.2016, at 19:37, Eric Anholt wrote:
>>>
>>> Martin Sperl writes:
>>>
>>>>> On 10.05.2016 03:
On 10.05.2016, at 21:58, Martin Sperl wrote:
>
>
>
>> On 10.05.2016, at 19:37, Eric Anholt wrote:
>>
>> Martin Sperl writes:
>>
>>>> On 10.05.2016 03:01, Eric Anholt wrote:
>>>> With the new patch 2 inserted between my previous pair
> On 10.05.2016, at 19:37, Eric Anholt wrote:
>
> Martin Sperl writes:
>
>>> On 10.05.2016 03:01, Eric Anholt wrote:
>>> With the new patch 2 inserted between my previous pair, I think this
>>> should cover Martin's bugs with clock disabling.
>
On 10.05.2016 03:01, Eric Anholt wrote:
With the new patch 2 inserted between my previous pair, I think this
should cover Martin's bugs with clock disabling.
I tested patch 2 to be important on the downstream kernel: with the
DPI panel support added there, I was losing ethernet (my only I/O)
whe
> On 02.05.2016, at 17:29, Eric Anholt wrote:
>
> Martin Sperl writes:
>
>>> On 26.04.2016, at 21:39, Eric Anholt wrote:
>>>
>>> If the firmware had set up a clock to source from PLLC, go along with
>>> it. But if we're looking for
On 30.04.2016 11:28, Martin Sperl wrote:
On 26.04.2016, at 21:39, Eric Anholt wrote:
If the firmware had set up a clock to source from PLLC, go along with
it. But if we're looking for a new parent, we don't want to switch it
to PLLC because the firmware will force PLLC (and thus t
> On 26.04.2016, at 21:39, Eric Anholt wrote:
>
> If the firmware had set up a clock to source from PLLC, go along with
> it. But if we're looking for a new parent, we don't want to switch it
> to PLLC because the firmware will force PLLC (and thus the AXI bus
> clock) to different frequencies
means control over the constraints is now transferred to the DAI
> driver and it's responsible to provide proper configuration and
> check for possible corner cases that aren't handled by the ALSA core.
>
> Signed-off-by: Matthias Reichl
Tested-by: Martin Sperl
sked out due to the PACK flag.
> - there are no further corner cases to catch in hw_params,
> since the channel count is fixed at 2 we always have two
> 16-bit stereo samples that can be transferred via 32-bit DMA
>
> Signed-off-by: Matthias Reichl
Tested-by: Martin Sperl
On 16.03.2016 20:24, Eric Anholt wrote:
Here's the series for DMA slave and memcpy support for 2835, with the
DT changes to enable the remaining channels dropped out while that
goes through review. I had to do some minor conflict resolution, but
it was pretty mechanical, and I tested again with
> On 19.03.2016, at 10:52, Stefan Wahren wrote:
>
> Hi,
>
>> Martin Sperl hat am 19. März 2016 um 08:44
>> geschrieben:
>>
>>
>>
>>> On 19.03.2016, at 03:17, Eric Anholt wrote:
>>>
>>> Stefan Wahren writes:
>>>
> On 19.03.2016, at 03:17, Eric Anholt wrote:
>
> Stefan Wahren writes:
>
>> Hi Eric,
>> hi Martin,
>>
>>> John Youn hat am 16. März 2016 um 19:28
>>> geschrieben:
>>>
>>>
>>> On 3/10/2016 11:14 AM, John Youn wrote:
On 3/9/2016 11:06 AM, Doug Anderson wrote:
>
> John: it's p
with dmatest on the last
patch.
Martin Sperl (8):
dmaengine: bcm2835: set residue_granularity field
dmaengine: bcm2835: remove unnecessary masking of dma channels
dmaengine: bcm2835: add additional defines for DMA-registers
dmaengine: bcm2835: move cyclic member from bcm2835_chan
I know it has already been merged, but while doing some
clock investigations of the RPI3 I came accross this code:
> On 09.10.2015, at 03:37, Eric Anholt wrote:
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index dd295e4..8502a4b 100644
> --- a/drivers/clk/bcm/cl
> On 03.03.2016, at 22:20, Stephen Warren wrote:
>
> On 02/26/2016 11:19 AM, Eric Anholt wrote:
>> The BCM2835-ARM-Peripherals.pdf documentation specifies what the
>> function selects do for the pins, and there are a bunch of obvious
>> groupings to be made. With these created, we'll be able to
> On 27.02.2016, at 00:05, Eric Anholt wrote:
>
> Here's a series to enable the SDHOST controller. It gives us better
> performance than our old sdhci-bcm2835.c. The downstream Raspberry Pi
> kernel appears to be using this controller by default at this point.
>
> I've tried to do some testin
dn't make it into
> 4.5 because required header files went through other trees.
>
>
> Alexander Aring (1):
> ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>
> Lubomir Rintel (1):
> ARM: bcm2835: dt: Add Raspberr
> On 18.12.2015, at 07:05, Vinod Koul wrote:
>
> On Thu, Dec 17, 2015 at 07:11:48PM +0100, Martin Sperl wrote:
>
>> +
>> +/* Setup addresses */
>> +if (d->dir == DMA_DEV_TO_MEM) {
>> +
m2835: enable dma modes for transfers meeting certain conditions”)
Signed-off-by: Noralf Trønnes
Tested-by: Martin Sperl
—
Patch was originally submitted by: Noralf Trønnes
Gellert Weisz has ended his internship with Raspberry Pi Trading and
was not available to sign off this patch.
The patch is
> On 02.12.2015, at 00:12, Mark Brown wrote:
>
> On Tue, Dec 01, 2015 at 04:51:06PM -, Michal Suchanek wrote:
>
>> +static inline size_t
>> +spi_max_transfer_size(struct spi_device *spi)
>> +{
>> +struct spi_master *master = spi->master;
>> +if (!master->max_transfer_size)
>> +
> On 16.09.2015, at 06:12, Stephen Warren wrote:
>
> On 09/04/2015 01:26 AM, Martin Sperl wrote:
>>
>>> On 26.08.2015, at 03:44, Stephen Warren wrote:
>>>
>>> On 08/24/2015 02:40 AM, ker...@martin.sperl.org wrote:
>>>
>>&g
er has a (hardcoded) internal clock divider 16,
while the hardware has an internal divider of 8.
This results in baud rates that are a factor of 2 higher than requested.
Tested-by: Martin Sperl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
thout issues.
Note that the DT bcm2835-rpi-b-plus.dtb can get used to boot
the compute module.
Thanks
Tested-by: Martin Sperl
--
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/
> On 10.09.2015, at 17:48, Noralf Trønnes wrote:
>
> This looks interesting.
> But there's a challenge with the uart1 and the 8250 driver.
>
> Phil Elwell has this to say:
> This means that that UART1 isn't an exact clone of a 8250 UART.
> In a particular, the clock divisor is calculated differ
> On 04.09.2015, at 17:37, Mark Brown wrote:
>
> On Fri, Sep 04, 2015 at 02:35:52PM +0200, Martin Sperl wrote:
>>> On 03.09.2015, at 14:12, Mark Brown wrote:
>
>>> This isn't saying that the controller supports more than one chip, it's
>>> s
> On 03.09.2015, at 14:12, Mark Brown wrote:
>
> On Wed, Aug 26, 2015 at 11:56:04AM +0530, Ranjit Waghmode wrote:
>
>> To support dual parallel mode operation of ZynqMP GQSPI controller
>> following API's are added inside the core:
>
> As covered in SubmittingPatches please try to make each pa
> On 26.08.2015, at 03:44, Stephen Warren wrote:
>
> On 08/24/2015 02:40 AM, ker...@martin.sperl.org wrote:
>
>> +Example:
>> +
>> +aux_enable: aux_enable@0x7e215004 {
>> +compatible = "bcrm,bcm2835-aux";
>> +reg = <0x7e215004 0x04>;
>
> I'd expect that to be <0x7e215000 0x8>;
The rea
On 8/6/2015 23:33, Russell King - ARM Linux wrote:
On Thu, Aug 06, 2015 at 06:14:00PM +0200, Geert Uytterhoeven wrote:
Irrespective of the dummy bytes.
What if the spi device is not a FLASH ROM, but some other device,
which receives a data packet that accidentally looks like an m25p80 READ
comm
> On 12.05.2015, at 17:58, Noralf Trønnes wrote:
>
> Is there something missing for this patch to get accepted?
> spi-bcm2835 has now DMA support that depends on this patch.
As the spi-bcm2835.c patch using DMA (relying on this) has gone into
spi/for-next (but so far without the DT changes to e
835_DMA_D_IGNORE.
So maybe we can add a “flag” to the dmaengine_prep_slave_sg
that will allow such kind of behavior to get implemented?
That is not a necessity, but would be a welcome improvement.
Tested-by: Martin Sperl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
ted using the bcm2835-mmc driver from the same repo.
>
> Signed-off-by: Noralf Trønnes
Tested-by: Martin Sperl
--
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.
> On 03.05.2015, at 11:59, Mark Brown wrote:
> Hrm, yes - that should work. I'd ask Greg, that's not something the bus
> implements.
It is still slightly more “complicated” from a distribution perspective,
but if that is what makes it a “clean” solution, then that is the way to
go forward.
I w
> On 30.04.2015, at 21:58, Mark Brown wrote:
>
> A big reason for that is that it's not in my inbox for me to review,
> these messages I flagged as unhelpful aren't going to help with that if
> only because I don't want to create the impression that such behaviour
> achieves results.
>
What ab
Tests with the initial (and incomplete) version of the spi-bcm2835 driver
with DMA transfer support show that the dma-engine works as expected with
this patch.
There is one one observation:
> On 18.04.2015, at 13:06, Noralf Trønnes wrote:
> +static struct dma_async_tx_descriptor *
> +bcm2835_d
> On 28.04.2015, at 03:21, Michael Welling wrote:
> If I were to attempt to convert the driver to use the core chipselect support,
> how would I go about doing it?
>
> Is there another driver that I can use for reference?
You may look into this patch: e34ff011c70e5f4ef219141711142d5111ae6ebb
for
> On 27.04.2015, at 17:27, Mark Brown wrote:
>
>
> OK, so that is just a default overlay which is abusing the fact that we
> will bind to spidev without a DT compatible and when the binding is
> undocumented (which also applies to other devices and buses sadly).
>
> Unfortunately nobody ever m
On 2015-04-27 13:25, Mark Brown wrote:
On Mon, Apr 27, 2015 at 12:04:12PM +0200, Hans de Goede wrote:
Have you seen my mail about the raspberry pi use-case? Using dt-overlays
simply is not an acceptable answer there. There are legitimate use-cases
for a "generic spi bus" concept with the bus on
> On 26.04.2015, at 13:23, Hans de Goede wrote:
> I think there is actual a use for just binding spidev as spidev,
> think e.g. the spi pins on the raspberry pi.
>
> How do you deal we suggest with such a situation ?
I actually asked the same question a few days ago on the spi list
(in thread:
> On 17.04.2015, at 19:08, Stefan Wahren wrote:
> i read the mail, but i'm still confused. Please let me paraphrase my last
> question:
>
> Is this patch testable with upstream kernel?
>
> It would be helpful to put those facts from the email to Alexander into
> the patch description. Please c
> On 15.04.2015, at 11:56, Noralf Trønnes wrote:
> +#define MAX_LITE_TRANSFER(SZ_64K - 1)
> +#define MAX_NORMAL_TRANSFER SZ_1G
...
> + if (c->ch >= 8) /* LITE channel */
> + max_size = MAX_LITE_TRANSFER;
> + else
> + max_size = MAX_NORMAL_TRANSFER;
> + per
> On 14.04.2015, at 06:24, Guenter Roeck wrote:
>
> by adding the now mandatory GPIOLIB dependency.
>
Note this shows up during automated randconfig testing.
> Fixes: a30a555d7435 ("spi: bcm2835: transform native-cs to gpio-cs
> on first spi_setup")
> Cc
On 01.03.2014, at 05:13, Mark Brown wrote:
> On Fri, Feb 28, 2014 at 11:03:16PM +0900, Atsushi Nemoto wrote:
>> Zero length transfer becomes invalid since
>> "spi: core: Validate length of the transfers in message" commit,
>> but it should be valid to support an odd device, for example, which
>> r
55 matches
Mail list logo
