[Letux-kernel] Request for tasks

H. Nikolaus Schaller hns at goldelico.com
Sun May 29 07:33:07 CEST 2016

Hi Andrey,

> Am 28.05.2016 um 15:14 schrieb Andrey Utkin <andrey_utkin at fastmail.com>:
> On Sat, May 28, 2016 at 01:30:56PM +0200, H. Nikolaus Schaller wrote:
>> Well, the key problem of the LKML review process is that you have something
>> working and well thought - but one of the thoughts is not accepted or understood
>> by maintainers. This means turning the code upside down and expand what had
>> been clean :)
> Well, LKML review requires huge amount of stubbornness

indeed. I just didn't find the right single word :)

Usually I can be quite stubborn on demand, but not for multiple topics in parallel...
Then I have to prioritize and one or the other isn't pushed as it were necessary. 

> (just as all
> driver work :) ). I know it because I'm now mainlining tw5864 driver for
> another job :)

interesting chip!

> In my experience maintainers are saint guys because they make most of
> work on evolution of API (and collateral changes across all drivers),
> which makes drivers more and more slim.

Yes, this is something to be appreciated... It would just be easier if it were better

>> But there are also work packages for new drivers where nobody did take care so far.
>> We have these sensor chips:
>> * BMC160
>> * BMG150
>> * or BNO055
>> * BME280
>> For some we don't have any or good enough (iio) drivers. Bosch Sensortec has some
>> libraries. And there are drivers for similar chips. So that could be a topic where you can
>> start from scratch and proceed in your own pace. And they are not too complex to start with.
> All of them at board, or some are substitusions for others? Please
> explain the "or" part.

The "or" means that it is not 100% finally decided if there will be BMC160+BMG150 or BNO055
and they have overlapping functionality.

> Please point me to all the datasheets once they become available for
> download.

I think for the sensors they are even public:


There is a user-space driver for the BNO055 but some iio kernel driver would be better:

> Are these chips available on any devboards anybody is having?

Yes, the prototypes have them (I am not sure about the BNO055 but it can even be retrofitted
and AFAIR there is no I2C address conflict).

> BTW what about some ready solution for sharing NDA files privately, for
> example, private Bitbucket git repo? It's free to set up and you can
> share access to persons you want.

Yes, it is a similar solution almost set up. I even have chosen and prepared the relevant data sheets.
They are just not copied to the right location on my server (and access permissions set up).

>> Another (almost) unprocessed task is the eMMC/µSD-Switch which IMHO should get a
>> driver that can switch between both on demand. My work so far is just a bindings document
>> to describe how *I* think it could be integrated into the DT. This is
>> issue http://projects.goldelico.com/p/gta04-kernel/issues/698/
>> and branch http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/mmc/txs02612
> Hm. Does it mean that eMMC and mSD cannot be accessed at the same time?
> (Which feel sad).

Well, it is a limitation of the OMAP5432 that it has just 4 MMC/SDIO ports and we need 5 (the OMAP5430
would have had a 5th one)...

We want:
2 big SD slots
1 eMMC
1 µSD

So we added an SDIO multiplexer which allows to use one interface for alternatively access
eMMC and µSD. There is also a hardware switch logic so that pressing a shoulder button chooses
which one will be used for the first and second stage boot loader. This is turned off by U-Boot so
that the switch is under 100% software control in Linux.

For Linux it would be nice if user space simply would 5 independent interfaces.

> I'm not keen on devicetree stuff, but just a dumb proposal - what about
> defining both, and then let the requests to blocked device (which is
> unavailable at the moment) return EIO or EAGAIN. If there's such thing
> as handler procedure, of course :)

Yes, would probably be a simple, manually operated solution for a start. We could
provide a private /sys node by the switch driver to throw the switch in either direction
(echo emmc >/sys/something).

In the long run I think the driver should correctly queue up requests and allow to
mix them by throwing the switch on demand. This will of course share the bandwidth
of the mmc interface.

What we need in any case is to properly tell the kernel that there is a switch sitting on
one specific omap hsmmc interface and that it provides two additional mmc ports. That is
what I hope the DT idea would allow to configure the driver. So that the driver can
register two new mmc ports (by mmc_add_host() ?) and it must itself register as
some mmc client (similar to the WLAN drivers).


More information about the Letux-kernel mailing list