linux-kernel - Re: HTC Dream aka. t-mobile g1 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a55d774e0906110148m69debe8fu9ff9970c0fe30bcd@mail.gmail.com>
Date:	Thu, 11 Jun 2009 01:48:57 -0700
From:	Brian Swetland <swetland@...gle.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	kernel list <linux-kernel@...r.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>,
	san@...roid.com, rlove@...gle.com, Greg KH <greg@...ah.com>
Subject: Re: HTC Dream aka. t-mobile g1 support

On Thu, Jun 11, 2009 at 1:25 AM, Pavel Machek<pavel@....cz> wrote:
> On Wed 2009-06-10 14:55:52, Brian Swetland wrote:
>> I'm not sure the smd (shared memory driver / virtual serial channels)
>> that everything else depends on makes sense outside of mach-msm, given
>> it's all very specific to the baseband and firmware that runs on it.
>
> Well, it is still a driver for your baseband chip, right?

Yes -- what I meant is more "does it belong under arch/arm/mach-msm/"
(given that it's very specific to that architecture and unlikely to
ever be useful elsewhere) or "does it belong somewhere else" (because
it's a pretty big pile of code compared to other stuff like
gpio/interrupt/etc stuff that tends to live under arch/arm/mach-*/).

> ...drivers/staging is _not_ final place for your code. When the code
> is good enough, it should move. But it is place where stuff like TI
> wifi driver would be acceptable.

Interesting -- reading up more on staging now.  I know that Greg KH
has been pulling some of the "generic" android drivers into staging
(Thanks, Greg!), but hadn't really looked at the rationale behind
staging in general.

Sounds like packing up the serial, sdio, nand, framebuffer, etc
drivers for submission into staging might make sense.  We can do the
obvious stuff like make sure they're checkpatch clean and reasonably
tidy first.

In order to actually have the peripherals work, though, we'd need to
add to board-*.c, devices.c, etc so that the platform devices are
defined so the platform drivers (which almost all of these are) are
actually probed.

>> Basically there's a stack:
>>
>> smsm  -- "shared memory state machine" (used for power collapse coordination)
>> smd -- "shared memory driver" (virtual serial channels, 8k bidirectional fifos)
>> rpcrouter/oncrpc -- rpc transport layer used for audio, audio routing, etc
>>
>> These are linux implementations of protocols the baseband speaks.
>>
>> Other stuff then stacks on smd (rmnet -- virtual ethernet, at control
>> channels, etc) and oncrpc (dsp control, rtc, gps, some media control).
>
> Is it all neccessary for boot? Getting it booting with display should
> be the first goal... GPS/RTC/... can come later.

The lowest layer IPC (proc_comm) is used for clock/power control and
is already in mainline, and that gets the clk_* framework functional
and allows most of the peripheral drivers to work, thankfully.  Things
like the serial driver, framebuffer, sdio, nand controller, etc all
should be happy without additional core architecture support.

Thanks,

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/